Ken Moffat via blfs-support
2018-10-14 20:55:38 UTC
My own /etc/logrotate.conf is slightly different from what is in the
book. In particular, I have been following the manpage and using a
postrotate command to kill the syslog.
/var/log/sys.log {
compress
rotate 4
weekly
postrotate
echo "rotating syslog"
/bin/killall -HUP syslogd
endscript
}
Up to and including LFS/BLFS-8.3 this worked fine (syslog gets
killed, so it stops writing to the old file). But on my two recent
svn systems I've noticed errors being reported. On a quick look, I
diudn't understand what it appeared to be telling me, so since the
boxes were working okay I left it until I had time to look.
Now that I have looked, I realised that it was 'killall' that was
barfing and giving me its "help" output, followed by an error
message from logrotate.
Manually trying variants of killall, killall -s failed to find
anything that worked, so in the end I used
/etc/rc.d/init.d/sysklogd restart
That works, I now get a fresh log (my current desktop is one of the
affected systems, it rotated a bit over 3 hours ago but was still
writing to sys.log.1 until I restarted sysklogd.
Is this a problem with the latest psmisc ?
I worry that my band-aid is doing rather too much (it takes several
seconds to run, maybe I'm losing kernel logging). I'm also puzzled
why the book does not have something like this in its example: do
other people's systems not continue to write to the moved
/var/log/sys.log.1 leaving sys.log empty until there is a reboot ?
ĸen
book. In particular, I have been following the manpage and using a
postrotate command to kill the syslog.
/var/log/sys.log {
compress
rotate 4
weekly
postrotate
echo "rotating syslog"
/bin/killall -HUP syslogd
endscript
}
Up to and including LFS/BLFS-8.3 this worked fine (syslog gets
killed, so it stops writing to the old file). But on my two recent
svn systems I've noticed errors being reported. On a quick look, I
diudn't understand what it appeared to be telling me, so since the
boxes were working okay I left it until I had time to look.
Now that I have looked, I realised that it was 'killall' that was
barfing and giving me its "help" output, followed by an error
message from logrotate.
Manually trying variants of killall, killall -s failed to find
anything that worked, so in the end I used
/etc/rc.d/init.d/sysklogd restart
That works, I now get a fresh log (my current desktop is one of the
affected systems, it rotated a bit over 3 hours ago but was still
writing to sys.log.1 until I restarted sysklogd.
Is this a problem with the latest psmisc ?
I worry that my band-aid is doing rather too much (it takes several
seconds to run, maybe I'm losing kernel logging). I'm also puzzled
why the book does not have something like this in its example: do
other people's systems not continue to write to the moved
/var/log/sys.log.1 leaving sys.log empty until there is a reboot ?
ĸen
--
Is it about a bicycle ?
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.ht
Is it about a bicycle ?
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.ht