sysklogd - Unix, Linux Command

System logging is provided by a version of
syslogd(8)
derived from the
stock BSD sources.  Support for kernel logging is provided by the
klogd(8)
utility which allows kernel logging to be conducted in either a
standalone fashion or as a client of syslogd.


Syslogd provides a kind of logging that many modern programs use.  Every logged
message contains at least a time and a hostname field, normally a
program name field, too, but that depends on how trusty the logging
program is.


While the
syslogd sources have been heavily modified a couple of notes
are in order.  First of all there has been a systematic attempt to
insure that syslogd follows its default, standard BSD behavior.
The second important concept to note is that this version of syslogd
interacts transparently with the version of syslog found in the
standard libraries.  If a binary linked to the standard shared
libraries fails to function correctly we would like an example of the
anomalous behavior.


The main configuration file
/etc/syslog.conf or an alternative file, given with the
-f option, is read at startup.  Any lines that begin with the hash mark
(‘‘#’’) and empty lines are ignored.  If an error occurs during parsing
the whole line is ignored.






This option is introduced in version 1.3 of the sysklogd
package.  Please note that the default behavior is the opposite of
how older versions behave, so you might have to turn this on.

kill -SIGNAL ‘cat /var/run/syslogd.pid‘

        # Sample syslog.conf
        daemon.debug                    /usr/adm/daemons


The * specifies that all messages for the
specified facility are to be directed to the destination.  Note that
this behavior is degenerate with specifying a priority level of debug.
Users have indicated that the asterisk notation is more intuitive.


The = wildcard is used to restrict logging to the specified priority
class.  This allows, for example, routing only debug messages to a
particular logging source.

        # Sample syslog.conf
        *.=debug                        /usr/adm/debug

        # Sample syslog.conf
        mail.*;mail.!=info              /usr/adm/mail
        news.info;news.!crit    /usr/adm/news



        mail.none

        mail.!*

        mail.!debug


to skip every message that comes with a mail facility.  There is much
room to play with it. :-)


The - may only be used to prefix a filename if you want to omit
sync’ing the file after every write to it.


This may take some acclimatization for those individuals used to the
pure BSD behavior but testers have indicated that this syntax is
somewhat more flexible than the BSD behavior.  Note that these changes
should not affect standard
syslog.conf(5)
files.  You must specifically
modify the configuration files to obtain the enhanced behavior.




To enable this you have to specify the
-r option on the command line.  The default behavior is that
syslogd won’t listen to the network.


The strategy is to have syslogd listen on a unix domain socket for
locally generated log messages.  This behavior will allow syslogd to
inter-operate with the syslog found in the standard C library.  At the
same time syslogd listens on the standard syslog port for messages
forwarded from other hosts.  To have this work correctly the
services(5)
files (typically found in
/etc) must have the following
entry:

        syslog          514/udp


To cause messages to be forwarded to another host replace
the normal file line in the
syslog.conf file with the name of the host to which the messages is to be sent
prepended with an @.

        # Sample syslogd configuration file to
        # messages to a remote host forward all.
        *.*                     @hostname


To forward all kernel messages to a remote host the
configuration file would be as follows:

        # Sample configuration file to forward all kernel
        # messages to a remote host.
        kern.*          @hostname


If the remote hostname cannot be resolved at startup, because the
name-server might not be accessible (it may be started after syslogd)
you don’t have to worry.
Syslogd will retry to resolve the name ten times and then complain.  Another
possibility to avoid this is to place the hostname in
/etc/hosts. 

With normal
syslogds you would get syslog-loops if you send out messages that were received
from a remote host to the same host (or more complicated to a third
host that sends it back to the first one, and so on).  In my domain
(Infodrom Oldenburg) we accidently got one and our disks filled up
with the same single message. :-(


To avoid this in further times no messages that were received from a
remote host are sent out to another (or the same) remote host
anymore.  If there are scenarios where this doesn’t make sense, please
drop me (Joey) a line.


If the remote host is located in the same domain as the host,
syslogd is running on, only the simple hostname will be logged instead of
the whole fqdn.


In a local network you may provide a central log server to have all
the important information kept on one machine.  If the network consists
of different domains you don’t have to complain about logging fully
qualified names instead of simple hostnames.  You may want to use the
strip-domain feature
-s of this server.  You can tell the
syslogd to strip off several domains other than the one the server is located
in and only log simple hostnames.


Using the
-l option there’s also a possibility to define single hosts as local
machines.  This, too, results in logging only their simple hostnames
and not the fqdns.


The UDP socket used to forward messages to remote hosts or to receive
messages from them is only opened when it is needed.  In releases
prior to 1.3-23 it was opened every time but not opened for reading or
forwarding respectively.



        # Sample configuration to route kernel debugging
        # messages ONLY to /usr/adm/debug which is a
        # named pipe.
        kern.=debug                     |/usr/adm/debug


This problem will typically manifest itself if old statically linked
binaries are being used on the system.  Binaries using old versions of
the syslog function will cause empty lines to be logged followed by
the message with the first character in the message removed.
Relinking these binaries to newer versions of the shared libraries
will correct this problem.


Both the
syslogd(8) and the 
klogd(8)
can either be run from
init(8)
or started as part of the rc.*
sequence.  If it is started from init the option -n must be set,
otherwise you’ll get tons of syslog daemons started.  This is because
init(8)
depends on the process ID.




There are a number of methods of protecting a machine:


Sucker rod def. — 3/4, 7/8 or 1in. hardened steel rod, male
threaded on each end.  Primary use in the oil industry in Western
North Dakota and other locations to pump ’suck’ oil from oil wells.
Secondary uses are for the construction of cattle feed lots and for
dealing with the occasional recalcitrant or belligerent individual.


Syslogd doesn’t change the filemode of opened logfiles at any stage of
process.  If a file is created it is world readable.  If you want to
avoid this, you have to create it and change permissions on your own.
This could be done in combination with rotating logfiles using the
savelog(8)
program that is shipped in the
smail 3.x distribution.  Remember that it might be a security hole if
everybody is able to read auth.* messages as these might contain
passwords.



klogd (8)
klogd (8)
logger (1)
logger (1)
syslog (2)
syslog (2)
savelog (8)
savelog (8)











Advertisements


    129 Lectures 
     23 hours 

 Eduonix Learning Solutions

    5 Lectures 
     4.5 hours 

 Frahaan Hussain

    35 Lectures 
     2 hours 

 Pradeep D

    41 Lectures 
     2.5 hours 

 Musab Zayadneh

    46 Lectures 
     4 hours 

 GUHARAJANM

    6 Lectures 
     4 hours 

 Uplatz
 Print
 Add Notes
 Bookmark this page