1 .\" Copyright 1994 Dr. Greg Wettstein, Enjellic Systems Development.
2 .\" Copyright 2004,6-8 Martin Schulze <joey@infodrom.org>
3 .\" May be distributed under the GNU General Public License
5 .TH SYSKLOGD 8 "11 May 2008" "Version 1.5" "Linux System Administration"
7 sysklogd \- Linux system logging utilities.
10 .RB [ " \-4" " ] [ " \-6 " ] [ " \-A " ]"
36 provides two system utilities which provide support for
37 system logging and kernel message trapping. Support of both internet and
38 unix domain sockets enables this utility package to support both local
41 System logging is provided by a version of
44 stock BSD sources. Support for kernel logging is provided by the
46 utility which allows kernel logging to be conducted in either a
47 standalone fashion or as a client of syslogd.
50 provides a kind of logging that many modern programs use. Every logged
51 message contains at least a time and a hostname field, normally a
52 program name field, too, but that depends on how trusty the logging
57 sources have been heavily modified a couple of notes
58 are in order. First of all there has been a systematic attempt to
59 insure that syslogd follows its default, standard BSD behavior.
60 The second important concept to note is that this version of syslogd
61 interacts transparently with the version of syslog found in the
62 standard libraries. If a binary linked to the standard shared
63 libraries fails to function correctly we would like an example of the
66 The main configuration file
68 or an alternative file, given with the
70 option, is read at startup. Any lines that begin with the hash mark
71 (``#'') and empty lines are ignored. If an error occurs during parsing
72 the whole line is ignored.
78 to use IPv4 addresses only.
83 to use IPv6 addresses only.
88 tries to send the message to only one address even if the host has
89 more than one A or AAAA record. If this option is specified,
91 tries to send the message to all addresses.
94 Using this argument you can specify additional sockets from that
96 has to listen to. This is needed if you're going to let some daemon
97 run within a chroot() environment. You can use up to 19 additional
98 sockets. If your environment needs even more, you have to increase
101 within the syslogd.c source file. An example for a chroot() daemon is
102 described by the people from OpenBSD at
103 <http://www.guides.sk/psionic/dns/>.
106 Turns on debug mode. Using this the daemon will not proceed a
108 to set itself in the background, but opposite to that stay in the
109 foreground and write much debug information on the current tty. See the
110 DEBUGGING section for more information.
112 .BI "\-f " "config file"
113 Specify an alternative configuration file instead of
114 .IR /etc/syslog.conf ","
115 which is the default.
118 By default syslogd will not forward messages it receives from remote hosts.
119 Specifying this switch on the command line will cause the log daemon to
120 forward any remote messages it receives to forwarding hosts which have been
122 This can cause syslog loops that fill up hard disks quite fast and
123 thus needs to be used with caution.
125 .BI "\-l " "hostlist"
126 Specify a hostname that should be logged only with its simple hostname
127 and not the fqdn. Multiple hosts may be specified using the colon
130 .BI "\-m " "interval"
133 logs a mark timestamp regularly. The default
135 between two \fI-- MARK --\fR lines is 20 minutes. This can be changed
136 with this option. Setting the
138 to zero turns it off entirely. Depending on other log messages
139 generated these lines may not be written consecutively.
140 The \fI-- MARK --\fR message is only written if the log file hasn't
146 Avoid auto-backgrounding. This is needed especially if the
148 is started and controlled by
152 You can specify an alternative unix domain socket instead of
156 This option will enable the facility to receive message from the
157 network using an internet domain socket with the syslog service (see
159 The default is to not receive any messages from the network.
161 This option is introduced in version 1.3 of the sysklogd
162 package. Please note that the default behavior is the opposite of
163 how older versions behave, so you might have to turn this on.
165 .BI "\-s " "domainlist"
166 Specify a domainname that should be stripped off before
167 logging. Multiple domains may be specified using the colon (``:'')
169 Please be advised that no sub-domains may be specified but only entire
170 domains. For example if
172 is specified and the host logging resolves to satu.infodrom.north.de
173 no domain would be cut, you will have to specify two domains like:
174 .BR "\-s north.de:infodrom.north.de" .
177 Print version and exit.
180 reacts to a set of signals. You may easily send a signal to
185 kill -SIGNAL `cat /var/run/syslogd.pid`
192 perform a re-initialization. All open files are closed, the
193 configuration file (default is
194 .IR /etc/syslog.conf ")"
195 will be reread and the
197 facility is started again.
204 .BR SIGINT ", " SIGQUIT
205 If debugging is enabled these are ignored, otherwise
210 Switch debugging on/off. This option can only be used if
217 Wait for childs if some were born, because of wall'ing messages.
218 .SH CONFIGURATION FILE SYNTAX DIFFERENCES
220 uses a slightly different syntax for its configuration file than
221 the original BSD sources. Originally all messages of a specific priority
222 and above were forwarded to the log file.
224 For example the following line caused ALL output from daemons using
225 the daemon facilities (debug is the lowest priority, so every higher
226 will also match) to go into
227 .IR /usr/adm/daemons :
231 daemon.debug /usr/adm/daemons
234 Under the new scheme this behavior remains the same. The difference
235 is the addition of four new specifiers, the asterisk (\fB*\fR)
236 wildcard, the equation sign (\fB=\fR), the exclamation mark
237 (\fB!\fR), and the minus sign (\fB-\fR).
239 The \fB*\fR specifies that all messages for the
240 specified facility are to be directed to the destination. Note that
241 this behavior is degenerate with specifying a priority level of debug.
242 Users have indicated that the asterisk notation is more intuitive.
244 The \fB=\fR wildcard is used to restrict logging to the specified priority
245 class. This allows, for example, routing only debug messages to a
246 particular logging source.
248 For example the following line in
250 would direct debug messages from all sources to the
256 *.=debug /usr/adm/debug
259 .\" The \fB!\fR as the first character of a priority inverts the above
260 .\" mentioned interpretation.
261 The \fB!\fR is used to exclude logging of the specified
262 priorities. This affects all (!) possibilities of specifying priorities.
264 For example the following lines would log all messages of the facility
265 mail except those with the priority info to the
267 file. And all messages from news.info (including) to news.crit
268 (excluding) would be logged to the
274 mail.*;mail.!=info /usr/adm/mail
275 news.info;news.!crit /usr/adm/news
278 You may use it intuitively as an exception specifier. The above
279 mentioned interpretation is simply inverted. Doing that you may use
293 to skip every message that comes with a mail facility. There is much
294 room to play with it. :-)
296 The \fB-\fR may only be used to prefix a filename if you want to omit
297 sync'ing the file after every write to it.
299 This may take some acclimatization for those individuals used to the
300 pure BSD behavior but testers have indicated that this syntax is
301 somewhat more flexible than the BSD behavior. Note that these changes
302 should not affect standard
304 files. You must specifically
305 modify the configuration files to obtain the enhanced behavior.
306 .SH SUPPORT FOR REMOTE LOGGING
307 These modifications provide network support to the syslogd facility.
308 Network support means that messages can be forwarded from one node
309 running syslogd to another node running syslogd where they will be
310 actually logged to a disk file.
312 To enable this you have to specify the
314 option on the command line. The default behavior is that
316 won't listen to the network.
318 The strategy is to have syslogd listen on a unix domain socket for
319 locally generated log messages. This behavior will allow syslogd to
320 inter-operate with the syslog found in the standard C library. At the
321 same time syslogd listens on the standard syslog port for messages
322 forwarded from other hosts. To have this work correctly the
324 files (typically found in
326 must have the following
333 If this entry is missing
335 neither can receive remote messages nor send them, because the UDP
336 port cant be opened. Instead
338 will die immediately, blowing out an error message.
340 To cause messages to be forwarded to another host replace
341 the normal file line in the
343 file with the name of the host to which the messages is to be sent
346 For example, to forward
348 messages to a remote host use the
354 # Sample syslogd configuration file to
355 # messages to a remote host forward all.
359 To forward all \fBkernel\fP messages to a remote host the
360 configuration file would be as follows:
363 # Sample configuration file to forward all kernel
364 # messages to a remote host.
369 If the remote hostname cannot be resolved at startup, because the
370 name-server might not be accessible (it may be started after syslogd)
371 you don't have to worry.
373 will retry to resolve the name ten times and then complain. Another
374 possibility to avoid this is to place the hostname in
379 you would get syslog-loops if you send out messages that were received
380 from a remote host to the same host (or more complicated to a third
381 host that sends it back to the first one, and so on). In my domain
382 (Infodrom Oldenburg) we accidently got one and our disks filled up
383 with the same single message. :-(
385 To avoid this no messages received from a
386 remote host are sent out to another (or the same) remote host
387 anymore. If you experience are setup in which you need this behaviour,
391 However, this option needs to be handled with caution since a syslog
392 loop can fill up hard disks quite fast.
394 If the remote host is located in the same domain as the host,
396 is running on, only the simple hostname will be logged instead of
399 In a local network you may provide a central log server to have all
400 the important information kept on one machine. If the network consists
401 of different domains you don't have to complain about logging fully
402 qualified names instead of simple hostnames. You may want to use the
405 of this server. You can tell the
407 to strip off several domains other than the one the server is located
408 in and only log simple hostnames.
412 option there's also a possibility to define single hosts as local
413 machines. This, too, results in logging only their simple hostnames
416 The UDP socket used to forward messages to remote hosts or to receive
417 messages from them is only opened when it is needed. In releases
418 prior to 1.3-23 it was opened every time but not opened for reading or
419 forwarding respectively.
420 .SH OUTPUT TO NAMED PIPES (FIFOs)
421 This version of syslogd has support for logging output to named pipes
422 (fifos). A fifo or named pipe can be used as a destination for log
423 messages by prepending a pipy symbol (``|'') to the name of the
424 file. This is handy for debugging. Note that the fifo must be created
425 with the mkfifo command before syslogd is started.
427 The following configuration file routes debug messages from the
431 # Sample configuration to route kernel debugging
432 # messages ONLY to /usr/adm/debug which is a
434 kern.=debug |/usr/adm/debug
437 .SH INSTALLATION CONCERNS
438 There is probably one important consideration when installing this
439 version of syslogd. This version of syslogd is dependent on proper
440 formatting of messages by the syslog function. The functioning of the
441 syslog function in the shared libraries changed somewhere in the
442 region of libc.so.4.[2-4].n. The specific change was to
443 null-terminate the message before transmitting it to the
445 socket. Proper functioning of this version of syslogd is dependent on
446 null-termination of the message.
448 This problem will typically manifest itself if old statically linked
449 binaries are being used on the system. Binaries using old versions of
450 the syslog function will cause empty lines to be logged followed by
451 the message with the first character in the message removed.
452 Relinking these binaries to newer versions of the shared libraries
453 will correct this problem.
456 .BR syslogd "(8) and the " klogd (8)
457 can either be run from
459 or started as part of the rc.*
460 sequence. If it is started from init the option \fI\-n\fR must be set,
461 otherwise you'll get tons of syslog daemons started. This is because
463 depends on the process ID.
465 There is the potential for the syslogd daemon to be
466 used as a conduit for a denial of service attack. Thanks go to John
467 Morrison (jmorriso@rflab.ee.ubc.ca) for alerting me to this potential.
468 A rogue program(mer) could very easily flood the syslogd daemon with
469 syslog messages resulting in the log files consuming all the remaining
470 space on the filesystem. Activating logging over the inet domain
471 sockets will of course expose a system to risks outside of programs or
472 individuals on the local machine.
474 There are a number of methods of protecting a machine:
476 Implement kernel firewalling to limit which hosts or networks have
477 access to the 514/UDP socket.
479 Logging can be directed to an isolated or non-root filesystem which,
480 if filled, will not impair the machine.
482 The ext2 filesystem can be used which can be configured to limit a
483 certain percentage of a filesystem to usage by root only. \fBNOTE\fP
484 that this will require syslogd to be run as a non-root process.
485 \fBALSO NOTE\fP that this will prevent usage of remote logging since
486 syslogd will be unable to bind to the 514/UDP socket.
488 Disabling inet domain sockets will limit risk to the local machine.
490 Use step 4 and if the problem persists and is not secondary to a rogue
491 program/daemon get a 3.5 ft (approx. 1 meter) length of sucker rod*
492 and have a chat with the user in question.
494 Sucker rod def. \(em 3/4, 7/8 or 1in. hardened steel rod, male
495 threaded on each end. Primary use in the oil industry in Western
496 North Dakota and other locations to pump 'suck' oil from oil wells.
497 Secondary uses are for the construction of cattle feed lots and for
498 dealing with the occasional recalcitrant or belligerent individual.
500 When debugging is turned on using
504 will be very verbose by writing much of what it does on stdout. Whenever
505 the configuration file is reread and re-parsed you'll see a tabular,
506 corresponding to the internal data structure. This tabular consists of
510 This field contains a serial number starting by zero. This number
511 represents the position in the internal data structure (i.e. the
512 array). If one number is left out then there might be an error in the
513 corresponding line in
514 .IR /etc/syslog.conf .
517 This field is tricky and represents the internal structure
518 exactly. Every column stands for a facility (refer to
520 As you can see, there are still some facilities left free for former
521 use, only the left most are used. Every field in a column represents
522 the priorities (refer to
526 This field describes the particular action that takes place whenever a
527 message is received that matches the pattern. Refer to the
529 manpage for all possible actions.
532 This field shows additional arguments to the actions in the last
533 field. For file-logging this is the filename for the logfile; for
534 user-logging this is a list of users; for remote logging this is the
535 hostname of the machine to log to; for console-logging this is the
536 used console; for tty-logging this is the specified tty; wall has no
537 additional arguments.
542 Configuration file for
546 for exact information.
549 The Unix domain socket to from where local syslog messages are read.
551 .I /var/run/syslogd.pid
552 The file containing the process id of
556 If an error occurs in one line the whole rule is ignored.
559 doesn't change the filemode of opened logfiles at any stage of
560 process. If a file is created it is world readable. If you want to
561 avoid this, you have to create it and change permissions on your own.
562 This could be done in combination with rotating logfiles using the
564 program that is shipped in the
566 3.x distribution. Remember that it might be a security hole if
567 everybody is able to read auth.* messages as these might contain
578 The system log daemon
580 is originally taken from BSD sources, Greg Wettstein <greg@wind.enjellic.com>
581 performed the port to Linux, Martin Schulze <joey@infodrom.org>
582 fixed some bugs, added several new features and took over maintenance.