■ OS Environment : Linux ( RHEL, Centos etc)
■ Resolution :
Whenever syslogd, the syslog dæmon, receives a log message, it acts based on the message's type (or facility) and its priority. syslog's mapping of actions to facilities and priorities is specified in /etc/syslog.conf. Each line in this file specifies one or more facility/priority selectors followed by an action. A selector consists of a facility or facilities and a (single) priority.
In the following syslog.conf line, mail.notice is the selector and /var/log/mail is the action (i.e., “write messages to /var/log/mail”):
Within the selector, “mail” is the facility (message category) and “notice” is the level of priority.
Facilities are simply categories. Supported facilities in Linux are auth, authpriv, cron, dæmon, kern, lpr, mail, mark, news, syslog, user, UUCP and local0 through local7. Some of these are self-explanatory, but of special note are:
* auth: used for many security events.
* authpriv: used for access-control-related messages.
* dæmon: used by system processes and other dæmons.
* kern: used for kernel messages.
* mark: messages generated by syslogd itself that contain only a timestamp and the string “--MARK--”. To specify how many minutes should transpire between marks, invoke syslogd with the -m [minutes] flag.
* user: the default facility when none is specified by an application or in a selector.
* local7: boot messages.
* *: wildcard signifying “any facility”.
* none: wildcard signifying “no facility”
Unlike facilities, which have no relationship to each other, priorities are hierarchical. Possible priorities in Linux are (in increasing order of urgency): debug > info > notice > warning > err > crit > alert and > emerg. Note that the urgency of a given message is determined by the programmer who wrote it; facility and priority are set by the programs that generate messages, not by syslog.
If you specify a single priority in a selector (without modifiers), you're actually specifying that priority plus all higher priorities. Thus the selector mail.notice translates to “all mail-related messages having a priority of notice or higher”, i.e., having a priority of notice, warning, err, crit, alert or emerg.
This behaviour can be cancelled by prepending an = to the priority. The selector mail.=notice translates to “all mail-related messages having a priority of notice”. Priorities may also be negated: mail.!notice is equivalent to “all mail messages except those with priority of notice or higher”, and mail.!=notice corresponds to “all mail messages except those with the priority notice”.
If overall system performance becomes an important factor in regard to logging, you can tell syslogd **not** to sync the disk each time it writes to a log file. This is done by putting a minus sign (-) in front of the file name, like this:
Sending the log messages to another machine is done by using an at-sign (@) in front of the machine name as the action. For example:
details abnout rsyslog : http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch05_:_Troubleshooting_Linux_with_syslog
The Linux utility logrotate renames and reuses system error log files on a periodic basis so that they don't occupy excessive disk space.
The /etc/logrotate.conf File :
This is logrotate's general configuration file in which you can specify the frequency with which the files are reused.
* You can specify either a weekly or daily rotation parameter. In the case below the weekly option is commented out with a #, allowing for daily updates.
* The rotate parameter specifies the number of copies of log files logrotate will maintain. In the case below the 4 copy option is commented out with a #, while allowing 7 copies.
* The create parameter creates a new log file after each rotation
Sample conf file:
# rotate log files weekly
# rotate log files daily
# keep 4 weeks worth of backlogs
# keep 7 days worth of backlogs
# create new (empty) log files after rotating old ones
The /etc/logrotate.d Directory :
Most Linux applications that use syslog will put an additional configuration file in this directory to specify the names of the log files to be rotated. It is a good practice to verify that all new applications that you want to use the syslog log have configuration files in this directory. Here are some sample files that define the specific files to be rotated for each application.
Here is an example of a custom file located in this directory that rotates files with the .tgz extension which are located in the /data/backups directory. The parameters in this file will override the global defaults in the /etc/logrotate.conf file. In this case, the rotated files won't be compressed, they'll be held for 30 days only if they are not empty, and they will be given file permissions of 600 for user root.
create 0600 root root
Activating logrotate :
The above logrotate settings in the previous section will not take effect until you issue the following command:
If you want logrotate to reload only a specific configuration file, and not all of them, then issue the logrotate command with just that filename as the argument like this:
[root@me]# logrotate -f /etc/logrotate.d/syslog
To compress log file use "compress" in main conf file.
How to check the logrotate status?
To check the current logrotate status, e.g. which files are covered by logrotate, what are their last processed date etc.
You can check the /var/lib/logrotate/status file