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.
I got it to work by changing ownership from messagebus.adm
to syslog.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:
-rw-r--r-- 1 root root 0 May 1 06:31 alternatives.log
drwxr-x--- 2 root adm 4096 Jun 9 06:46 apache2
drwxr-xr-x 2 root root 4096 Jun 1 06:48 apt
-rw-r----- 1 messagebus adm 0 Oct 22 2012 auth.log
-rw-r----- 1 root adm 0 Oct 22 2012 boot
-rw-r--r-- 1 root root 0 Oct 22 2012 boot.log
-rw-r--r-- 1 root root 0 Oct 22 2012 bootstrap.log
-rw-rw---- 1 root utmp 2688 Jun 6 10:31 btmp
drwxr-xr-x 2 root root 4096 Oct 18 2012 ConsoleKit
drwxr-xr-x 2 root root 4096 Oct 16 2012 dist-upgrade
-rw-r----- 1 root adm 11669 Jun 6 13:16 dmesg
-rw-r--r-- 1 root root 24494 Jun 6 11:30 dpkg.log
-rw-r----- 1 root adm 117 Jun 9 06:46 fail2ban.log
-rw-r--r-- 1 root root 24024 Apr 11 10:36 faillog
-rw-r--r-- 1 root root 1202 Apr 10 19:13 fontconfig.log
drwxr-xr-x 2 root root 4096 Oct 18 2012 fsck
drwxr-xr-x 3 root root 4096 Oct 18 2012 installer
-rw-r----- 1 messagebus adm 0 Oct 22 2012 kern.log
drwxr-xr-x 2 syslog root 4096 Oct 18 2012 landscape
-rw-rw-r-- 1 root utmp 292292 Jun 9 10:38 lastlog
-rw-r----- 1 messagebus adm 0 Oct 22 2012 mail.err
-rw-r----- 1 messagebus adm 0 Oct 22 2012 mail.log
drwxr-s--- 2 mysql adm 4096 Jun 9 06:46 mysql
-rw-r----- 1 mysql adm 0 Apr 29 07:48 mysql.err
-rw-r----- 1 mysql adm 0 Jun 9 06:46 mysql.log
drwxr-xr-x 2 root root 4096 Oct 18 2012 news
drwxr-xr-x 2 ntp ntp 4096 Aug 20 2012 ntpstats
drwxr-xr-x 2 nobody nogroup 4096 Apr 10 23:00 passenger-analytics
-rw-r----- 1 syslog adm 3538 Jun 9 11:10 syslog
drwxr-xr-x 2 root root 4096 May 24 2012 sysstat
-rw-r--r-- 1 root root 285653 Jun 6 13:15 udev
-rw-r----- 1 messagebus adm 0 Oct 22 2012 ufw.log
drwxr-xr-x 2 root root 4096 Jun 8 06:29 upstart
-rw-rw-r-- 1 root utmp 44928 Jun 9 10:38 wtmp
Does this look correct?
Edit: related discussion here.
Best Answer
TL;DR :
The problem was due to the file
var/log/syslog
being very large in size withkernel
especiallyufw
dumping a lot ofUFW_AUDIT
logs regularly. To solve the problem we need to set theLOGLEVEL
ofufw
aslow
in theufw
configuration file/etc/ufw/ufw.conf
:From
man ufw
:DETAILS :
There might be many reasons why the error
is shown. The most common two being the file is too large in size to be read and file has unusual contents that could not be read.
At first we have considered the first cause i.e. file is too big (i will show the steps one by one as we have done it):
At first we need to check how many lines are there in
/var/log/syslog
and it turned out to be quite unusual:As the file has 1308061 number of lines which is quite big, we need to check how the
logrorate
is configured forrsyslog
by:This have shown that
/var/log/syslog
will rotate every day with logs older than one week being deleted, which is the default.Next we need to check
/var/log/syslog
to see which process is writing most logs to the file using the command:This will show us the processes written most lines in the file in a descending order. We found that
kernel
has written to file the highest with the count being very high (1761519). The next isthermald
with its several processes wrote about 5K times.Considering 1kernel1 as the source of this anomaly, we have checked for a pattern in the
/var/log/syslog
that is occurring regularly by:and found one that was about
UFW AUDIT
and it was very very regularly writing in the log file.ufw
will dump these messages if theLOGLEVEL
is set asmedium
and more. To find the current value:Thats the source of the problem, to get rid of these regular messages it needs to be
LOGLEVEL=low
, it should be sufficient in most cases. Fromman ufw
:Check the
LOGGING
section ofman ufw
to get more idea onufw
logging.