Hack82.Force Standalone Apps to Use syslog

Hack 82. Force Standalone Apps to Use syslog

Some applications insist on maintaining their own set of logs. Here's a way to shuffle those entries over to the standard syslog facility.

The dream is this: working in an environment where all infrastructure services are running on Linux machines [Hack #44] using easy-to-find open source software such as BIND, Apache, Sendmail, and the like. There are lots of nice things about all these packages, not the least of which is that they all know about and embrace the standard Linux/Unix syslog facilities. What this means is that you can tell the applications to log using syslog, and then configure which log entries go where in one file (syslog.conf), instead of editing application-specific configuration files.

For example, if I want Apache to log to syslog, I can put a line like this one in my httpd.conf file:

 ErrorLog syslog 

This will, by default, log to the local7 syslog facility. You can think of a syslog facility as a channel into syslog. You configure syslog to tell it where entries coming in on a given channel should be written. So, if I want all messages from Apache coming in on the local7 channel to be written to /var/log/httpd, I can put the following line in /etc/syslog.conf:

 local7.* /var/log/httpd 

You can do this for the vast majority of service applications that run under Linux. The big win is that if an application misbehaves, you don't have to track down its logfilesyou can always consult syslog.conf to figure out where your applications are logging to.

In reality, though, most environments are not 100% Linux. Furthermore, not all software is as syslog-friendly as we'd like. In fact, some software has no clue what syslog is, and these applications maintain their own logfiles, in their own logging directory, without an option to change that in any way. Some of these applications are otherwise wonderful services, but systems people are notoriously unrelenting in their demand for consistency in things like logging. So here's the meat of this hack: an example of a service that displays selfish logging behavior, and one way to go about dealing with it.

Fedora Directory Server (FDS) can be installed from binary packages on Red Hatbased distributions, as well as on Solaris and HP-UX. On other Linux distributions, it can be built from source. However, on no platform does FDS know anything about the local syslog facility. Enter a little-known command called logger.

The logger command provides a generic shell interface to the syslog facility on your local machine. What this means is that if you want to write a shell or Perl script that logs to syslog without writing syslog-specific functions, you can just call logger from within the script, tell it what to write and which syslog facility to write it to, and you're done!

Beyond that, logger can also take its input from stdin, which means that you can pipe information from another application to logger, and it will log whatever it receives as input from the application. This is truly beautiful, because now I can track down the FDS logs I'm interested in and send them to syslog with a command like this:

 # exec tail -f /opt/fedora-ds/slapd-ldap/logs/access.log | logger -p local0. debug & 

I can then tell my syslog daemon to watch for all of the messages that have been piped to logger and sent to syslog on local0 and to put them in, say, /var/ log/ldap/access.log.

The debug on the end of the facility name is referred to in syslog parlance as a priority. There are various priority levels available for use by each syslog facility, so a given application can log messages of varying severity as being of different priorities [Hack #86]. FDS is a good example of an application where you'd want to utilize prioritiesthe access log for FDS can be extremely verbose, so you're likely to want to separate those messages into their own logfile. Its error log is rarely written to at all, but the messages there can pertain to the availability of the service, so you might want those messages to go to /var/log/messages. Rather than using up another whole syslog facility to get those messages to another file, just run a command like this one:

 # tail -f /opt/fedora-ds/slapd-ldap/logs/error.log | logger -p local0.notice 

Now let's tell syslog to log the messages to the proper files. Here are the configuration lines for the access and error logs:

 local0.debug /var/log/ldap/access.log local0.notice /var/log/messages 

There is one final enhancement you'll probably want to make, and it has to do with logger's output. Here's a line that made it to a logfile from logger as we ran it above, with just a -p flag to indicate the facility to use:

 Aug 26 13:30:12 apollo logger: connection refused from 192.168.198.50 

Well, this isn't very useful, because it lists logger as the application reporting the log entry! You can tell logger to masquerade as another application of your choosing using the -t flag, like this:

 # tail -f access.log | logger -p local0.debug -t FDS 

Now, instead of the reporting application showing up as logger:, it will show up as FDS:.

Of course, there are probably alternatives to using logger, but they sometimes involve writing Perl or PHP daemons that perform basically the same function as our logger solution. In the long run, you may be able to come up with a better solution for your site, but for the "here and now" fix, logger is a good tool to have on your toolbelt.