System Logging explained in Linux

Log files form the life line of any system administrator. They help pin point any discrepancies in the day to day functioning of the OS. Naturally Linux has an excellent logging facility whose work is done by the syslogd and klogd daemons. In RedHat/Fedora, you start these daemons by the command :

# service syslog start

The above command will start both syslogd and klogd daemons. These daemons will read the configuration file /etc/syslog.conf and start logging messages accordingly.

syslogd - receives messages from many daemons.
klogd - logs kernel messages.

What is the use of monitoring log files ?
Monitoring log files will help detect the following:

1. Equipment problems such as hard disk crashes or power outages.
2. User problems such as repeated login failures.
3. Security breaches from outside the system.
   

Most common log files and their purposes
/var/log/messages - Logs most system messages
/var/log/secure - Authentication messages, xinetd services

/var/log/vsftpd.log - FTP transactions (Usually this file will be named different if you are using a FTP server other than vsftpd).

/var/log/maillog - Mail transactions.

The information contained in /var/log/messages include the following:

• Date and time the message was written.
• Name of the utility, program or daemon that caused the message.
• Action that occurred.
• Executing program's hostname.
  

Note: Many applications also create their own log files which may also need to be monitored.

Syslogd and Klogd configuration

These two daemons are configured using the /etc/syslog.conf file. The format of the file is quite simple as shown below :

#Syntax of syslog.conf file
facility.priority log_location

... where facility can be any of the following:

• authpriv - security / authorization messages
• cron - clock daemons (atd and crond)
• daemon - other daemons
• kern - kernel messages
• local[0-7] - reserved for local use
• lpr - printing system
• mail - mail system
• news - news system
• syslog - internal syslog messages
• user - generic user level messages
  

... and the priorities are as follows:

• debug - debugging information
• info - general informative messages
• notice - normal, but significant, condition
• warning - warning messages
• err - error condition
• crit - critical condition
• alert - immediate action required
• emerg - system no longer available
  

A few examples to whet your appetite

kern.info /dev/tty0

The above rule will direct all kernel informational messages to the first console. For example, after entering this rule, and restarting syslogd and klogd, try restarting a service. You will find the message on your /dev/tty0 console.

mail.crit ravi,root

This will send all critical messages pertaining to mail to the console logged in by root and ravi.

*.emerg *
Everybody gets emergency messages from all facilities.

kern.=!info;mail.=!debug /var/log/my_special_messages

Log all kernel messages except with priority info and all mail messages other than debug to the file my_special_messages.

authpriv.none;cron.none /var/log/messages
Do not log private authentication messages.

Note: As shown in the examples above, logging can be further specified with certain operators.

• = - log on only this exact priority
• ! - Exclude this facility or priority
• * - Log all facilities / priorities
  

Specify a comma separated list of users who will be notified.You can also use a named pipe (|) for use with external logging programs (|/name/of/pipe). The pipe has to exist before syslogd starts.

As you can see, Linux has a very good robust logging mechanism. And its strong point is that it enables one to change the parameters by editing plain text files - /etc/syslog.conf in this case. It is important to know that each time you make changes to the syslog.conf file, you have to restart the syslog daemon to bring those changes into effect.