[Home]

The syslog daemon


One of the first places to look for warning or error messages is in the UNIX syslog file (/usr/adm/syslog). How do the messages get there? and How is it possible to customise it?

The flexible and often-overlooked syslog facility provides system administrators with fine-grained control over error messages. When used to its fullest, syslog can make the administrator's job much easier by organising log information. A well-designed, centralised logging facility also can augment security by providing a virtually incorruptible logging facility.

On Windows NT, the syslog service is emulated using the Event Log.

Unix utilities and your own applications (including scripts) can use the syslogd daemon to send messages. Each message sent to syslog has a facility and a priority associated with it. The facility indicates which sub-system the message originated from, and the priority relates to how important the message is.

Note: The information is this guide relates specifically to SCO Unix 3.2v5.0.x, however, syslogd is available on most Unix platforms so the principles here will apply.

Facilities recognised by /etc/syslogd are defined in the array facilitynames and priority levels in the array prioritynames both contained in /usr/include/sys/syslog.h

The Configuration File

The way in which the syslog daemon (/etc/syslogd) handles messages is defined in the configuration file /etc/syslog.conf (can be changed with the -f option). The syntax is simple.:

Each 'action' line in the configuration file defines one possible course of action. The line is composed of two parts separated by at least one <TAB> and white space.

The first part is a list of facility and priority pairs (the selectors) separated by semicolons, for example *.notice;mail.info. You can specify multiple facilities if they are separated via commas e.g. kern,mark.debug which is the same as kern.debug;mark.debug.

The second part is an action. The action field describes where the message is to be logged if the line is selected, action can take one of the following forms:

ActionWhat
pathname Open the specified file or device file in append mode; The file must already exist
the file must be specified by an absolute pathname beginning with a leading slash (/).
@hostname Forward selected messages to syslogd on the host named by hostname.
user[,user]... Write selected messages to the comma-separated list of users if they are logged in.
* Write selected messages to all logged-in users.

To be logged, the incoming message must have come from the named facility and must have a priority equal to or higher than the one listed in syslog.conf. For example, the pair mail.warning will match any syslog message from the mail (facility) sub-system with priority warning or higher (e.g. err, crit, alert and emerg).

The asterisk can be used to indicate all facilities, so *.info specifies all logged messages at priority level info and higher for all facilities.

The level none can be used to deselect a facility, so *.info;mail.none specifies all messages at or above info except for mail facility messages.

Each action line will be processed in turn and if the selectors match the action will be taken. This can lead to duplication, take the following two lines:

mail.info /usr/adm/maillog
*.debug /usr/adm/syslog

Any event from the mail facility will be logged in syslog (as per *.debug) AND mail with a priority of info and higher (as per mail.info) will be logged in maillog. To avoid this you should specify mail.none on the *.debug line e.g. *.debug;mail.none .

Some examples from the man page:

What is it being logged under?

There may be times when the documentation does not indicate what an event is logged as. To find this out you should switch on debugging for /etc/syslogd as follows:

  • Kill the existing /etc/syslogd daemon
  • Run it for a period with the -d flag e.g.

    /etc/syslogd -d 2>&1 >/tmp/syslog.debug &

    This will log details to the file /tmp/syslog.debug as per:

    logmsg: pri 56, flags 4, from xanth, msg syslogd: restart
    logmsg: pri 26, flags 0, from xanth, msg May 14 18:05:00 rshd[29567]: connect from xanth
    logmsg: pri 5, flags 4, from xanth, msg %Stp-0    -  -   -  Vendor=HP Product=C1533A
    logmsg: pri 26, flags 0, from xanth, msg May 14 20:28:12 telnetd[1689]: connect from portable
    logmsg: pri 64, flags 0, from hplaser, msg  printer: toner/ink low  
    logmsg: pri 63, flags 0, from hplaser, msg  printer: paper out  
    logmsg: pri 26, flags 0, from xanth, msg May 15 13:27:30 popper[10233]: connect from kate
    logmsg: pri 25, flags 0, from xanth, msg May 15 13:27:30 popper[10233]: (v2.1.4-R3) Servicing request from "kate" at 192.168.10.88
    

    The important piece of information is the pri xxx

    Taking

    logmsg: pri 25, flags 0, from xanth, msg May 15 13:27:30 popper[10233]: (v2.1.4-R3) Servicing request from "kate" at 192.168.10.88
    

    as an example, this entry came from the popper program and was logged at level 25. The level is in octal.

    You should be aware, that when running with the -d option not all events will be logged. Some events (timemarks) are generated by alarm calls to syslogd and these are disabled in this mode. Take care when looking at the log file as all (normal) events are reported as being received even if they are later discarded and it is easy to think a change to syslog.conf has not worked.

    Using this information you can configure your system so that the correct events are logged in the correct files e.g.

    # TCP Wrappers - Normally logged under mail - change in tcpd Makefile 
    local0.*		/usr/adm/tcpdlog
    
    # Make sure the popper messages go else where
    mail.info					/usr/adm/maillog
    
    # Keep an eye on local scripts by sending to testbox
    local7.*				@testbox
    
    # Everything except mail and tcpd messages to syslog
    *.debug;mail,local0.none			/usr/adm/syslog
    

    loghost - or centralised administration

    An administrator in charge of a network of UNIX machines needs to centralise the logs. It is much easier to check for abnormalities on one machine than on 30. Allocate one of the server's to be the central 'loghost' and configure syslog on that host to suit your needs. Then change all other hosts to redirect logging information to loghost.

    This can be done with a single line in syslog.conf:

    *.debug @loghost

    If you feel some messages need to be logged on the local machine or to the console, put in configuration lines for those.

    Note: Some versions of syslogd may need an additional flag to indicate that they should listen for remote requests (usually on port 514) - refer to the man page for details.

    logger - Logging your own messages

    In addition to having Unix utilities log information you can, by using the logger (C) (and syslogd(SLIB)) include commands in your own programs and shell scripts routines to add syslog entries.

    Examples

    Log messages as priority level info in the local3 facility:

    While the man page indicates you can use either the 'numeric option ( <number>)' or 'Symbolic (<facility.priority>)' in message text e.g. logger "<local0.debug> foobar failed" - you can't. All messages sent to syslog via logger will be at user.info unless the -p option is used. Any text passed to logger will be included in syslog unchanged.

    If you must use the <number> option then you can write directly to the device /dev/logfifo e.g.

    Numeric priorities are generated by : facility * 8 + priority e.g. mail.info = 2 * 8 + 6 = 22

    The string ``%m'' within a message is replaced by the current error message (corresponding the global error number, errno): e.g.

    If a message is not specified, the contents of the file specified using the -f option are logged; otherwise, the standard input is logged until EOF is encountered. The other useful option is -t for tag. e.g. The tag will appear before the message, if the -t option is not used then it will default to your user id. For example:

    Telling /etc/syslogd to re-read the conf file

    If changes have been made to /etc/syslogd.conf then you need to "refresh" the syslog daemon so it notices them.

    This is done by sending a "hangup" (HUP) signal to the syslog daemon. The easy way to do this is to do a "kill -1" with the syslog daemon's process ID (PID) number. e.g.

    # ps -ef | grep syslog
        root 16091     1  0   May-15       ?    00:00:00 /etc/syslogd
        root 17200 17199  3 13:45:52   ttyp3    00:00:00 grep syslog
    
    # kill -1 16091
    

    At that point you should have your first message(s) logged. It will say something to the effect that the "syslog has restarted".

    For instance, on SCO OpenServer Release 5:

        May 17 13:45:59 testbox syslogd: re-initialise
        May 17 13:45:59 testbox syslogd: restart
    
    If you see something like this in your syslog file, then you know that logging is working.

    Summary

    Syslog is underutilised at many installations. Its ability to log events to different files and forward to remote systems can vastly improve pro-active management of a network. Used in conjunction with programs such as TCP Wrappers you can have centralised security logging that is difficult to foil.


    Comments and suggestions always welcome - tom@tkrh.demon.co.uk