One of the things I like doing on systems that I design is local logging. Useful for debugging, seeing what’s going on generally and also as an aid for users and techs to see what went wrong and how. Now logging during one off installs is fine and you wouldn’t think too much of that. Continuous logging is a different matter, and conceivably you could run into disk space issues as your files balloon over time.
Not good. In the Unix world, you’d just use log rotate which at a certain file size create a new file and rotate the old file into a “logfile.log.1” or “.2” and so on depending on how you configure it.
Problem. That doesn’t exist on macOS unless you install it yourself. This is not that guide.
Apple decided to use a different technology called newsyslog instead and like a lot of other background tech, there’s some unix style configuration files to deal with. Unlike unix, there’s a specific folder in /etc called newsyslog.d that you can place files into.
So we can just generate a configuration file per log file and place it in that folder? Well that gets unwieldly quickly and I prefer a one off type solution. So based on the fact I like to keep organisation specific log files in their own folder, here’s an example of what I do:
1) Create a log folder in /var/log and give it a recognisable name.
2) We need to create a configuration file for newsyslog to deal with that folder. You can use different methods for this, but in this case I’ve scripted my way through and it looks like this:
# Script to set up log rotation automatically for the org log folder
cat > /etc/newsyslog.d/organisation.conf << CONFIGEND
# logfilename [owner:group] mode count size when flags [/pid_file] [sig_num]
/var/log/organisation/*.log 644 5 1024 * JG
A little explanation of what this is doing. I’m setting up a series of text that I am cat’ing out to a file in /etc/newsyslog.d called organisation.conf.
The top line is present in all the existing files on macOS, so I’ve left it there just in case. It provides some but not much explanation of what to do.
The second line is more interesting. Let’s go section by section:
- First section is the path to where we want to rotate files, complete with a wildcard *.log to capture everything. This is important because you don’t want to do any of the rotated logs that have a different file extension!
- Second section is the chmod permissions. I’m leaving this at 644, which allows non admin users to read only.
- Third section, the “5” shows how many rotations we want to keep. Your file will go through five rotations before eventually being purged from the system.
- Fourth section is the max size of the file in kilobytes. The 1024 means i’m setting it for 1Mb files, which is quite large for pure text.
- Fifth section is just a “*”. We don’t know or care about the PID of the process that created the logs in the first place.
- Sixth and last is the “JG”. The J says that I want bzip2 rotated files (compression good!) and G that I’m using wildcards in the specified path. Quite important that last one.
There’s a manual page for all this. You can find it here.
3) There is no step three! You can deploy this however you like. Create a pkg and deploy with your favourite tool. Use the script in the same manner, the end result is the same. Any file located in your specified folder will not balloon out as the OS will check things every 30 minutes. Incidentally that’s set in the launchdaemon in /System so not sure if you could or would want to change that.
I now have log rotation working on a folder of my choice. It works, it’s reliable and I don’t worry about users running out of disk space due to my info collection.