Syslog is a standard logging facility. It collects messages of various programs and services including the kernel, and stores them, depending on setup, in a bunch of log files typically under /var/log
. In some datacenter setups there are hundreds of devices each with its own log; syslog comes in handy here too. One just sets up a dedicated syslog server which collects all the individual device logs over the network. Syslog can also save logs to databases, and other clients.
According to my /etc/syslog.conf
, default /var/log/kern.log
captures only the kernel's messages of any loglevel; i.e. the output of dmesg
.
/var/log/messages
instead aims at storing valuable, non-debug and non-critical messages. This log should be considered the "general system activity" log.
/var/log/syslog
in turn logs everything, except auth related messages.
Other insteresting standard logs managed by syslog are /var/log/auth.log
, /var/log/mail.log
.
2020 update
You may still stumble upon syslog; but the defaults have changed.
journald
has replaced syslog, in quite a big portion of systems, including Ubuntu.
This is relevant because you won't be finding /var/log/messages
that often anymore. journald
doesn't write plaintext logs — it uses its own, compressed and partially authenticated format.
Search online for e.g. journalctl cheatsheet, or just study man 8 systemd-journald
, man 1 journalctl
yourself.
Syslog and journald are, to a degree, cross-compatible; you can transport logs between them in either direction. However, you won't get plaintext logs a-la /var/log/messages
with journald; and you won't get structured (journalctl -o json-pretty
) and authenticated logging with syslog.
From what I can see, your 50-default.conf file matches the default, so that's probably not the problem: http://bazaar.launchpad.net/~ubuntu-branches/ubuntu/quantal/rsyslog/quantal/view/head:/debian/50-default.conf
Happily, it looks like rsyslog has a config-checking mode that should help you troubleshoot what is actually going on. From their help page:
Rsyslog 3.21.1 and above has been enhanced to support extended
configuration checking. It offers a special command line switch (-N1)
that puts it into "config verfication mode". In that mode, it
interprets and check the configuration file, but does not startup.
This mode can be used in parallel to a running instance of rsyslogd.
To enable it, run rsyslog interactively as follows:
/path/to/rsyslogd -f/path/to/config-file -N1
You should also specify other options you usually give (like -c3 and
whatever else). Any problems experienced are reported to stderr [aka
"your screen" (if not redirected)].
http://www.rsyslog.com/doc/troubleshoot.html
Best Answer
I got it to work by changing ownership from
messagebus.adm
tosyslog.adm
, and then restarting rsyslog.Kind of disturbing that this broke silently. Given this experience I am not terribly confident that the other log files are owned properly. Here's what I have currently:
Does this look correct?
Edit: related discussion here.