Hmmm.... is rsyslog failing to write things to files?
Apr 07 15:15:01 sochi rsyslogd: action 'action 6' suspended (module
'builtin:omfile'), retry 0. There should be messages before this one giving the
reason for suspension. [v8.32.0 try http://www.rsyslog.co
Apr 07 15:15:01 sochi rsyslogd: action 'action 6' resumed (module
'builtin:omfile') [v8.32.0 try http://www.rsyslog.com/e/2359 ]
I see a lot of stuff like that from rsyslog.
syslog 2023 0.0 0.0 347096 5648 ? Ssl Apr06 0:08
$ ls -latr auth.log
-rw-r----- 1 root adm 0 Jul 14 2014 auth.log
How can a syslog user write to a root owned file?
<insert mem gif of geometry confusion / does not compute>
$ sudo chown syslog:adm /var/log/auth.log; sudo systemctl restart
Seems to fix things for me, and auth.log is getting entries... My guess
is that /usr/lib/tmpfiles.d/00rsyslog.conf is incomplete? and that we
need to override more permissions in it?
In that case, it sounds like a bug in rsyslog, for not having right
permissions specified in tmpfiles.d?
** Changed in: rsyslog (Ubuntu Bionic)
Importance: Undecided => Critical
** Changed in: systemd (Ubuntu Bionic)
Importance: Critical => Medium
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to rsyslog in Ubuntu.
journald takes over /dev/log in bionic, impacts usability of syslog
Status in rsyslog package in Ubuntu:
Status in systemd package in Ubuntu:
Status in rsyslog source package in Bionic:
Status in systemd source package in Bionic:
In bionic, /dev/log is now owned by systemd-journald.
$ sudo fuser -v /dev/log
USER PID ACCESS COMMAND
root 1 F.... systemd
root 628 F.... systemd-journal
This is ok; there are good reasons to want to do this. (Timestamp
precision that's not dependent on the syslog protocol; logging
available earlier in boot and later at shutdown; unified queriability
of logs around services.)
The logfiles previously populated by rsyslog under /var/log are now
empty (no longer being updated, and the previous files logrotated
$ ls -l /var/log/auth.log
-rw-r----- 1 syslog adm 0 Mar 25 00:06 /var/log/auth.log
This is also ok, we don't really want log data duplicated in two
places on the system; so since we now have persistent journal under
/var/log/journal, we don't want to also create these plaintext files
However, it's not clear that this is by design, rather than by
accident. rsyslog is still /configured/ to log to these files; it
just isn't receiving any data because it no longer controls the
$ sudo lsof -p 852|grep DGRAM
rsyslogd 852 syslog 3u unix 0xffff8e5680435000 0t0 351
Dimitri and I have discussed that rsyslog should continue to function,
so that users who have remote syslogging configured can still make use
of this. It looks like currently this is not the case, because
journald is not forwarding to rsyslog.
That is not ok.
What is also not ok is that, now that logs are only being written to
the journal by default instead of to syslog files, querying these logs
by syslog priority only works if you know the syslog facility by
number (and, afaics, you can only filter by one syslog facility at a
time). So whereas before, you could find mail logs by looking in
/var/log/mail.log by default, you now have to know to run 'journalctl
SYSLOG_FACILITY=2'; and if you want a view of what was previously in
/var/log/syslog (i.e. filtering out non-syslog systemd logs, it seems
the most compact way to express this is 'journalctl --system
This is really not good. Admins have never needed to know the mapping
of symbolic names to facility numbers to work with syslog; this throws
away 30 years of convention with log handling.
If we are going to store the logs in the journal by default, I think
there needs to be a way to query the logs using symbolic names
consistent with syslog(3) and /etc/rsyslog.d/50-default.conf.
I don't think we can release with things in the current state.
To manage notifications about this bug go to:
Mailing list: https://launchpad.net/~touch-packages
Post to : firstname.lastname@example.org
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp