When bash scripting, a useful command is logger. The logger command allows you to “make entries in the system log.” When using the logger command, you can write to your own entries to the system log. To show how this command works, we’re going to open two terminal windows, preferably side-by-side. In one window, we’re going to look at the output of the system.log file interactively using the tail command with the -f option
tail -f /private/var/log/system.log
In the other window, we’re going to simply enter the logger command followed by the word frogger:
logger frogger
This will show you an entry similar to the following:
Jun 3 00:34:44 ce.pretendco.com krypted[77276]: frogger
Congrats, you’ve successfully written your own log entry into the system log. Now that you’ve done that, go ahead and press the up arrow on your keyboard to see the line again and then hit enter. You’ll then see the same line, with the pid more than likely incremented up by one. The pid is the process id of the logger command you just ran. If you run ps you’ll note that the pid is no longer in use.
Next, we’ll create a text file called froggerlog in our home directory, populating it with just the string: mylogdata. This is meant to emulate having written some data into a log file. We’ll do so using the echo command:
echo mylogdata > froggerlog
Now that we have a file, use the -f option to include the contents of the file into the system.log, specifying the path to the file:
logger -f ~/froggerlog
You will then see something like the following, with your mylogdata string in it:
Jun 3 00:37:24 ce.pretendco.com krypted[77279]: mylogdata
Using that structure, you can write data into a file and then later dump that data into the log, so as not to fill up the system.log file with tons of random data as it happens. Or you can write directly into the log as needed. It’s good to have choices.
The -i option is used to include the pid for the logger process in each line. But if you go back and add a second line of data into your log file, and re-run the logger command against that file you’ll notice that the pid is included with each line the same no matter whether you use the -i or not, making the -i unnecessary. You will also note that consecutive rows with the same information simply say — last message repeated 1 time —. This helps to keep log files a bit more trim than they otherwise might be if you have, say, 10,000 lines with the same content:
Jun 3 00:50:57 ce.pretendco.com krypted[588]: mylogdata
Jun 3 00:51:17 ce.pretendco.com krypted[588]: 1234
Jun 3 00:51:17 --- last message repeated 1 time ---
Jun 3 00:51:17 ce.pretendco.com krypted[588]: abc
Now, you might find it difficult to see only the pertinent lines to your script. Use the -t option to tag a line, followed by the tag. For example, let’s add myscript into our lines, continuing to write into the system.log using the froggerlog file from earlier:
logger -t myscript -f ~/froggerlog
Note the output contains the myscript tag in front of the pid, in place of the username you were writing entries as:
Jun 3 00:56:28 ce.pretendco.com myscript[601]: mylogdata
Jun 3 00:56:28 ce.pretendco.com myscript[601]: 1234
Jun 3 00:56:28 --- last message repeated 1 time ---
Jun 3 00:56:28 ce.pretendco.com myscript[601]: abc
Messages can be written at various priorities. To set the priority of your entries, use the -p option. After that enter the priority as an integer, using the following:
- Alert: Level 1
- Error: Level 3
- Warning: Level 4
- Notice: Level 5
- Info: Level 6
- Debug: Level 7
For example, to write an alert entry (everyone should see this):
logger -t myscript -f ~/froggerlog -p alert
To write a debug log:
logger -t myscript -f ~/froggerlog -p debug
The alert log is shown but the debug is not. Levels 5-7 are not displayed using a tail of system.log. If you need to verify success or failure of entries, note that logger exits 0 on success but not when an error is encountered. If you’d like to output entries to standard error, you can do so by adding the -s option as well.
