Re: [blfs-support] Odd issue with killall in logrotate.conf (sysv)
On 10/17/2018 04:25 PM, Ken Moffat via blfs-support wrote: On Sun, Oct 14, 2018 at 09:50:56PM -0500, Bruce Dubbs via blfs-support wrote: On 10/14/2018 08:25 PM, Ken Moffat via blfs-support wrote: On Sun, Oct 14, 2018 at 09:55:38PM +0100, Ken Moffat via blfs-support wrote: Is this a problem with the latest psmisc ? Possibly, https://gitlab.com/psmisc/psmisc/issues/13 If so, it has been fixed upstream. My test earlier in the ticket was for psmisc-23.1, so that psmisc-23.2 may be a problem. -- Bruce Definitely is. I'd forgotten about this, then went to kill the running firefox in a way that would save current state (rather than whatever the last saved state was) so that I could try a freshly compiled test version (i.e. killall -HUP firefox) - got the same thing. This _will_ randomly break scripts. Note that I have not tested upstream to confirm it *does* fix it. What's curious is that psmisc appears to be fixed upstream about a month ago, but there is no release to fix the problem for general users. -- Bruce -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Odd issue with killall in logrotate.conf (sysv)
On Sun, Oct 14, 2018 at 09:50:56PM -0500, Bruce Dubbs via blfs-support wrote: > On 10/14/2018 08:25 PM, Ken Moffat via blfs-support wrote: > > On Sun, Oct 14, 2018 at 09:55:38PM +0100, Ken Moffat via blfs-support wrote: > > > > > > Is this a problem with the latest psmisc ? > > > > > Possibly, https://gitlab.com/psmisc/psmisc/issues/13 > > > > If so, it has been fixed upstream. > > My test earlier in the ticket was for psmisc-23.1, so that psmisc-23.2 may > be a problem. > > -- Bruce > Definitely is. I'd forgotten about this, then went to kill the running firefox in a way that would save current state (rather than whatever the last saved state was) so that I could try a freshly compiled test version (i.e. killall -HUP firefox) - got the same thing. This _will_ randomly break scripts. Note that I have not tested upstream to confirm it *does* fix it. ĸen -- Is it about a bicycle ? -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Odd issue with killall in logrotate.conf (sysv)
On Sun, Oct 14, 2018 at 09:55:38PM +0100, Ken Moffat via blfs-support wrote: > > Is this a problem with the latest psmisc ? > Possibly, https://gitlab.com/psmisc/psmisc/issues/13 If so, it has been fixed upstream. -- Is it about a bicycle ? -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
Re: [blfs-support] Odd issue with killall in logrotate.conf (sysv)
On Sun, Oct 14, 2018 at 04:32:18PM -0500, Bruce Dubbs via blfs-support wrote:
> On 10/14/2018 03:55 PM, Ken Moffat via blfs-support wrote:
> > 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
> > }
>
> The difference between that and the book is very minor. you added compress
> and echo and removed the size option.
>
I see it now, in the logrotate.d/ directory.
> > 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
>
> On the command line of my 9.3 system I did:
>
> $ sudo killall -HUP syslogd
>
> And then in /var/log/sys.log I have:
>
> Oct 14 16:22:28 frodo83 syslogd 1.5.1: restart.
>
> So that appears to work for me.
>
> > 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 do not think so. Works for me.
>
> > 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:
>
> It does.
>
OK, I accept that part.
> 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 ?
>
> I've not checked that. I have not installed fcron, but I will and get back
> to you if I see a problem.
>
> -- Bruce
For the record, here is what I got from the last logrotate before I
made the change. I hd initially assumed something in logrotate
itself had changed (skimmed the message, looked particularly at the
end).
From: root@origin (fcron)
To: ken@milliways.mydomain
Subject: fcron /usr/sbin/logrotate /etc/logrotate.conf
rotating syslog
Usage: killall [OPTION]... [--] NAME...
killall -l, --list
killall -V, --version
-e,--exact require exact match for very long names
-I,--ignore-casecase insensitive process name match
-g,--process-group kill process group instead of process
-y,--younger-than kill processes younger than TIME
-o,--older-than kill processes older than TIME
-i,--interactiveask for confirmation before killing
-l,--list list all known signal names
-q,--quiet don't print complaints
-r,--regexp interpret NAME as an extended regular expression
-s,--signal SIGNAL send this signal instead of SIGTERM
-u,--user USER kill only process(es) running as USER
-v,--verbosereport if the signal was successfully sent
-V,--versiondisplay version information
-w,--wait wait for processes to die
-n,--ns PID match processes that belong to the same namespaces
as PID
error: error running non-shared postrotate script for /var/log/sys.log of
'/var/log/sys.log '
rotating minor log(s)
rotating power management logs
rotating power management logs
Job '/usr/sbin/logrotate /etc/logrotate.conf' terminated (exit status: 1)
(mailing output)
--
Is it about a bicycle ?
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
Re: [blfs-support] Odd issue with killall in logrotate.conf (sysv)
On 10/14/2018 03:55 PM, Ken Moffat via blfs-support wrote:
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
}
The difference between that and the book is very minor. you added
compress and echo and removed the size option.
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
On the command line of my 9.3 system I did:
$ sudo killall -HUP syslogd
And then in /var/log/sys.log I have:
Oct 14 16:22:28 frodo83 syslogd 1.5.1: restart.
So that appears to work for me.
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 do not think so. Works for me.
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:
It does.
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 ?
I've not checked that. I have not installed fcron, but I will and get
back to you if I see a problem.
-- Bruce
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
