Ad hoc logging with logger

logger
Credit: flickr / Jeremy Rempel

If you write as many scripts as I do to monitor services and check the status of various processes that run on your servers, you might like knowing that having those scripts sending you email is not the only way to make sure that you stay on top of the things those scripts are trying to tell you. Another option is to add your messages and alerts to the system logs -- with logger.

Logger is a general purpose messaging tool that works with syslog to direct your messages to the log files of your choice. And, if you later scan your logs for all of the messages that you need to take some action on, there they will be, never dropped into your spam folder or lost among a pile of other messages that land in your inbox.

And, fortunately, logger is very easy to use. The simplest example, something like logger "message" will add the string that you specify to the /var/log/messages file along with the date and time.

$ logger "The bottom just fell out"
$ sudo tail -1 /var/log/messages
Mar 22 13:17:45 boson slee: The bottom just fell out

Note that your username ("slee" in this example) is included to show who added the message. The name of the system ("boson") is also included. Notice also that slee is able to add the message even though she is not allowed to even view the content of the messages file on her own.

$ tail -1 /var/log/messages
tail: cannot open `/var/log/messages' for reading: Permission denied

Logger is most often used within scripts and, as you'd likely imagine, allows various parameters to be attached to the messages being assembled to make them more significant and useful. Add a line like this to a script and it will add a line with the script name and a failure indication to /var/log/messages.

#!/bin/bash

file=$1
tail $file

[ "$?" != "0" ] &&  logger "$0 failed -- $file not found""

If we run this script and then examine the bottom of the log file, we will see the line that has been added to annotate the problem the script ran into -- namely that the file it assumed would be provided as a parameter either doesn't exist or we don't have permission to look at it.

In the output shown below, we are running the script. Note that we see the error that is generated and that logger adds an error message to the messages file.

$ ./oops /apps/stats
tail: cannot open `/apps/stats' for reading: No such file or directory
$ sudo tail -1 /var/log/messages
Mar 22 13:55:41 boson slee: ./oops failed -- /apps/stats not found

You can also add a "tag" to your messages, such as a severity indicator, by making use of the -t option. Here's an example of an error that will be logged with a WARNING tag.

#!/bin/bash

pgrep crond
[ "$?" != "0" ] &&  logger -t WARNING "cron deamon is not running"

And when we run this script and then examine the messages file, we see the error with the WARNING tag prepended to it.

$ ./chkcron
$ sudo tail -1 /var/log/messages
Mar 22 14:04:36 boson WARNING: cron deamon is not running

Crafting your messages can involve more than just specifying the details that you want to see in the file. You can also control which log file the messages are added to. In the example below, we do this by using the -p (priority) option.

$ logger -p news.crit "This is critical news"
$ sudo tail -1 /var/log/spooler
Mar 22 14:11:25 boson slee: This is critical news

If you're wondering how we selected the spooler log, that's a good question! This log was selected to receive our message because it's listed in the /etc/syslog.conf file as the destination for messages that are issued using the "news.crit" designator. Here are the two lines from the syslog.conf file that set this up.

# Save news errors of level crit and higher in a special file.
uucp,news.crit            /var/log/spooler

Using the "emerg" priority, we see that the message (in this case "911") that we are generated both gets echoed to the screen and lands in the messages file.

$ logger -p emerg 911
$
Message from syslogd@ at Tue Mar 22 14:32:09 2016 ...
boson slee: 911
$
$ sudo tail -2 /var/log/messages
Password:
Mar 22 14:26:35 boson logger: print "month=$mo; year=$yr\n";
Mar 22 14:32:09 boson slee: 911

These messages go to both the screen and the messages file because of this entry in the /etc/syslog.conf file.

# Everybody gets emergency messages
*.emerg                                  *

You can also add the contents of any arbitrary file to the log file. Just use the -f option. Note that every line will be prepended with the date, time, system, and "logger" entry.

$ logger -f errors
$ sudo tail -4 /var/log/messages
Mar 22 14:26:35 boson logger: chkvars service restarted
Mar 22 14:26:35 boson logger: no errors noted
Mar 22 14:26:35 boson logger:
Mar 22 14:26:35 boson logger: hourly monitoring has begun

The errors file contains the four lines shown.

chkvars service restarted
no errors noted

hourly monitoring has begun

This option might be very useful if you've collected significant details in another file and then want to be sure that it gets added to the messages file as well.

Sending significant entries to your log files can help ensure that you're capturing the kind of data that will help you with monitoring your systems. And logger makes it possible to add those details to just the right log files.

This article is published as part of the IDG Contributor Network. Want to Join?

The brave new world of Windows 10 license activation
View Comments
Join the discussion
Be the first to comment on this article. Our Commenting Policies