• Choose a category
• All
• Classic-Fiction

Later versions of syslogd replace the fixed table with a linked list but still include another constant, MAXUNAMES (also 20), that limits the number of users who can be the destination of a message.

When invoked with the -d (debug) flag, syslogd displays a table of the facilities, levels, and actions specified in the syslog.conf file. Each incoming message is also echoed to the screen along with information about how it is being processed. Here are a few rows from such a table:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 X WALL:

7 X 4 6 6 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 X FILE: /adm/msgs

X X X X X X 7 X X X X X X X X X X X X X X FILE: /adm/lperr

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 UNUSED:

0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 UNUSED:

In this table, columns correspond to facilities and rows to actions. The values displayed are the priority levels as represented internally; an X means none.

If there are lines in the table that have the tag UNUSED and no action, you still have fewer than NLOGS destinations. If you don’t see any such lines, make sure you have not exceeded the limit; check your configuration file by probing the last entry in your syslog.conf file with logger. Lines with both UNUSED and a filename mean that you have forgotten to create the log file.

Be careful about logging to the console device, /dev/console. If the console is an old VT100 terminal and someone has inadvertently typed on it, output to the console will stop. Each call to syslog will block, and your system will slow to a crawl. A good way to check for this degenerate condition is to send a syslog message to the console via logger. If logger hangs, you need to find the offending console, type a , and rethink your logging strategy.

Another drawback to logging on the console is that the flood of messages sparked by a major problem can make the console unusable at precisely the moment that it is most needed. Depending on how your console is set up and managed (e.g., through a console server), console logging may also have some security implications.

Using syslog from programs

The library routines openlog, syslog, and closelog allow programs to use the syslog system. Versions of these library routines are available for both C and Perl; we will describe only the Perl interface here. To import the definitions of the library routines, include the line

use Sys::Syslog;

at the beginning of your Perl script.

The openlog routine initializes logging, using the specified facility name:

openlog(ident, logopt, facility);

Messages are logged with the options specified by logopt and begin with the identification string ident. If openlog is not used, ident defaults to the current username, logopt to an empty string, and facility to “user”. The logopt string should contain a comma-separated list of the options shown in Table 11.8.

Table 11.8 Logging options for the openlog routine

For example, a reasonable invocation of openlog might be

openlog("adminscript", "pid,cons", "daemon");

The syslog routine sends a message to syslogd, which logs it at the specified priority:

syslog(priority, message, ...);

The date, time, hostname, and ident string from the openlog call are prepended to the message in the log file. message may be followed by various other parameters to form a printf-style output specification that can include text and the contents of other variables; for example,

syslog("info", "Delivery to '%s' failed after %d attempts.", $user, $nAttempts);

The special symbol %m expands to an error message derived from the current value of errno (the most recent UNIX error code).

A priority string of the form “level| facility” sets both the severity level and the facility name. If you did not call openlog and specify an ident string, the syslog routine also checks to see if your message has the form of a standard UNIX error message such as

adminscript: User "nobody" not found in /etc/passwd file.

If it does, the part before