Results 1 to 2 of 2


  1. #1


    Hello all,
    Here is my tutorial about Linux system logs. All comments/suggestions are welcomed.

    So lets go to the tutorial:

    ***BOF ***

    ----- cut here -------------------------------------------------------------------------------------------


    Copyright (C) 2004 Gigabite All rights reserved.

    You may distribute this tutorial freely, as long as no changes are made to the document. The copyright, disclaimer and the signature MUST be included with the document.


    Although I have taken every precaution in the preparation of this tutorial, I will assume no responsibility for errors or omissions. Neither is any liability assumed for the information contained herein.



    -/var/log contains various system logs for tasks performed on your system. You can find logs for mail , news, and all other system operations. /var/log/messages file is a log of all system tasks not covered by other logs (such as loading drivers and mounting file systems). Logins are also logged in this file, showing you who attempted to log in to what account. The /var/log/maillog file logs mail message transmissions and news transfers.

    -Logs are managed by the syslogd daemon, all the logs on your system as well as coordinating with the logging operations of other systems on your network are managed by this daemon.
    Configuration information for syslogd is held in the /etc/syslog.conf file. This file contains the names and locations for your system log files. Here you find entries for /var/log/messages and /var/log/maillog , among others.

    -An entry consists of two fields:
    a selector and an action.
    The selector is the kind of service to be logged, such as mail or news, and the action is the location where messages are to be placed. The action is usually a log file, but it can also be a remote host or a pipe to another program. The kind of service is referred to as a facility. syslogd has several terms it uses to specify certain kinds of service:

    auth-priv Security / authorization messages (Private)
    cron Clock daemon (Cron and at) messages
    daemon Other system daemon messages
    kern Kernel messages
    lpr Line printer subsystem messages
    mail mail subsystem messages
    mark Internal use only
    news Usenet news subsystem messages
    syslog syslog internal messages
    user Generic user-level messages
    uucp UUCP subsystem messages
    local0 through local7 reserved for local use

    Priorities Description
    debug 7, debugging messages, lowest priority
    info 6, Informational messages
    notice 5, Notifications, normal, but significant condition
    warning 4, Warnings
    err 3, Error messages
    crit 2, Critical conditions
    alerts 1, Alerts, highest priority

    Operators Description
    * Matches all facilities or priorities in a sector
    = Restricts to a specified priority
    ! Excludes specified priority and higher ones
    / A file to save messages to
    @ A host to send messages to
    | FIFO (First In First Out) pipe to send messages to

    -A facility can be further qualified by a priority. A priority specifies the kind of messages generated by the facility. syslogd uses several designated terms to indicate different priorities. A sector is constructed from both the facility and priority, separated by a period (.).
    For example to save error messages generated by mail systems, you use a sector consisting of the mail facility and the err priority, as shown bellow:


    -To save these messages to the /var/log/maillog file you specify that file as the action, as shown bellow:

    mail.err /var/log/maillog

    -syslogd also supports the use of * as a matching character to match either all the facilities or priorities in a sector. Cron.* would match on all cron messages no matter what the priority, *.err would match on error messages from all the facilities, and *.* would match on all messages.
    For example, we can save all mail messages to the /var/log/maillog file and all critical messagesto the /var/log/mycritical file as shown bellow:

    mail.* /var/log/maillog
    *.crit /var/log/mycritical

    -When a priority is specified for a facility, that in fact will include the crit , alert and emerg priorities. If you just want to select the message for a specific priority, you qualify the priority with the = operator.
    For example, mail.=err will only select error messages, not crit, alert and emerg messages. You can also restrict priorities with the ! operator.This will eliminate messages with the specified priority and higher. For example mail.!crit will exclude crit messages and the higher alert and emerg messages.
    To specifically exclude all the messages for a specified facility, you use the none priority. mail.none excludes all mail messages. This is usually done when you define several sectors in the same entry.

    -You can also have several sectors in the same entry by separating them with semicolons (. In the example bellow we will save to /var/log/messages file all messages with info priority, excluding all mail, news and authentication messages (authpriv):

    *.info; mail.none; news.none; authpriv.none /var/log/messages

    In the example bellow we will save all crit messages and higher for the uucp and news facilities to the /var/log/spooler file:

    uucp, news.crit /var/log/spooler

    -For the action field, you can specify files, remote systems, users, or pipes.
    An action entry for a file must always begin with a / and specify its full pathname, such as /var/log/messages .
    To log messages to a remote host, you simply specify the hostname preceded by an @ sign. The following example will save all kernel messages on :


    -For users, you just list the login names of the users you want to receive the messages. The example bellow will send critical news messages to the consoles for the users gigabite and gigabyte :

    news.=crit gigabite, gigabyte

    You can also output messages to a named pipe (FIFO). The pipe entry for the action field begins with a |. In the following example we will pipe kernel debug messages to the named pipe |/usr/admin/debug :

    kern.=debug |/usr/admin/debug

    Whenever you make changes to the syslog.conf file, the syslogd daemon should be restarted. This can be done as shown bellow:

    /etc/rc.d/initd/syslog restart


    ----- cut here -------------------------------------------------------------------------------------------


    Hope that the tutorial was helpfull and you all enjoyed reading it.
    The FACT that people ignore FACTS
    doesnt mean that FACTS are not FACTS

  2. #2
    I just wanted to say thanks this was very helpful

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts