Var adm messages not updating

Posted by / 23-Apr-2020 07:17

This has been plaguing my systems since moving from syslog-ng, which I may return to as it seems it was actually production ready.Without manually restarting those files don't exist so here's what I did on an 11.04 system: logrotate --force --verbose /etc/gives: rotating pattern: /var/log/syslog forced from command line (7 rotations) empty log files are not rotated, old logs are removed considering log /var/log/syslog log /var/log/syslog does not exist -- skipping not running postrotate script, since no logs were rotated rotating pattern: /var/log//var/log//var/log//var/log//var/log//var/log//var/log//var/log//var/log//var/log//var/log/debug /var/log/messages forced from command line (4 rotations) empty log files are not rotated, old logs are removed considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log does not need rotating considering log /var/log/log does not need rotating considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/log /var/log/does not exist -- skipping considering log /var/log/debug log /var/log/debug does not exist -- skipping considering log /var/log/messages log /var/log/messages does not exist -- skipping not running postrotate script, since no logs were rotated Then /sbin/reload rsyslog logger -i testing At this point there is no /var/log/syslog Then: /sbin/restart rsyslog And voila there is a /var/log/syslog beginning with: Feb 23 somehost kernel: imklog 4.6.4, log source = /proc/kmsg started.It seems File Group ("adm") survives but File Owner is the dbus-daemon UID.After reading "man initctl --reload" I wonder if this is caused if for some reason the 'rsyslogd' process has died/stopped during logrotate and therefore a new instance is started by dbus-daemon which (initially? Looking back through the rotated "syslog" I noticed that the PID of rsyslogd hasn't changed when it was HUPed: Aug 21 hush rsyslogd: [origin software="rsyslogd" sw Version="5.8.11" x-pid="2647" x-info=" start Aug 21 hush rsyslogd: rsyslogd's groupid changed to 103 Aug 21 hush rsyslogd: rsyslogd's userid changed to 101 Aug 21 hush rsyslogd-2039: Could not open output pipe '/dev/xconsole' [try rsyslogd was HUPed But I guess it could have died whilst re-creating the files, which may lead to it being restarted with the dbus-daemon user "messagebus" user file-ownership credentials.

In my case, "/sbin/reload rsyslog" does not cause rsyslog to reopen the file handles and it instead continues writing to the rotated files, e.g. ls -ltr /var/log | tail -rw-r----- 1 syslog adm 0 Aug 19 -rw-rw---- 1 root utmp 0 Sep 1 btmp.1 -rw-r--r-- 1 root root 252 Sep 7 -rw-rw-r-- 1 root utmp 15360 Sep 29 wtmp.1 -rw-rw---- 1 root utmp 0 Oct 1 btmp -rw-r----- 1 syslog adm 605488 Oct 10 1 -rw-rw-r-- 1 root utmp 4224 Oct 10 wtmp -rw-rw-r-- 1 root utmp 292876 Oct 10 lastlog -rw-r----- 1 syslog adm 17692156 Oct 10 1 -rw-r----- 1 syslog adm 3045212 Oct 10 syslog.1 postrotate command seems wrong anyway: # cat /etc/logrotate.I know from the other bug permissions were an issue but they seem not to be in this case: -rw-r----- 1 syslog adm 0 2012-02-23 -rw-r----- 1 syslog adm 79 2012-02-23 -rw-r----- 1 syslog adm 350 2012-02-23 syslog In any case, the solution seems to be updating /etc/logrotate./var/log# tail -f syslog Jun 28 helen kernel: imklog 5.8.6, log source = /proc/kmsg started.Jun 28 helen rsyslogd: [origin software="rsyslogd" sw Version="5.8.6" x-pid="3986" x-info=" start Jun 28 helen rsyslogd: rsyslogd's groupid changed to 103 Jun 28 helen rsyslogd: rsyslogd's userid changed to 102 Jun 28 helen rsyslogd-2039: Could not open output pipe '/dev/xconsole' [try Only check if jobs are disabled if the currently _running_ version of # Upstart (which may be older than the latest _installed_ version) # supports such a query.Since our monitoring script notified us that one of our domains wasn’t responding for a few minutes last time, I checked all files in /var/log on the server hosting this domain.Unfortunately I couldn’t find anything since /var/log/messages was actually not being written to.# Su SEconfig –module syslog-ng Starting Su SEconfig, the Su SE Configuration Tool…

var adm messages not updating-5var adm messages not updating-8var adm messages not updating-62

UPSTART_I'm also seeing this on a 12.04 minimal install.

One thought on “var adm messages not updating”