Re: Strange syslog behaviour [Solved]
On Sun 16 Oct 2022 at 09:09:36 (-0400), Wayne Sallee wrote:
> I wrote:
> > On Sat 15 Oct 2022 at 13:59:18 (-0400), Wayne Sallee obfuscated the following with HTML:
> >
> > > Jeremy Ardley, did you update your code from " invoke-rc.d rsyslog rotate > /dev/null" to
> > > "/usr/lib/rsyslog/rsyslog-rotate"?
> > I've added a new post to that part of the thread. I think your
> > problem concerns changing to systemd, whereas his concerns mixing
> > inetdutils-* packages with the more usual equivalent ones.
> >
> > > So I got my servers straitened out, I think. I will know tomorrow.
> > > For anyone else running into this problem, the problem was caused from modifying
> > > /etc/logrotate.d/rsyslog then upgrading to Buster.
> > > The fix:
> > > diff /etc/logrotate.d/rsyslog.dpkg-dist /etc/logrotate.d/rsyslog
> > > edit /etc/logrotate.d/rsyslog
> > > Change from
> > > invoke-rc.d rsyslog rotate > /dev/null
> > > to
> > > /usr/lib/rsyslog/rsyslog-rotate
> > > Then delete /etc/logrotate.d/rsyslog.dpkg-dist
> > > I then rebooted my servers to get the syslog used.
> > > Then
> > > ls /var/log | grep syslog
> > > To see that it was working. I will know tomorrow if it is still working.
> > I think the point you've missed is that at some stage, you upgraded
> > from SystemV to systemd. Whenever that happened, the upgrade to
> > rsyslog would have supplied a new /etc/logrotate.d/rsyslog file
> > containing "/usr/lib/rsyslog/rsyslog-rotate", which knows how to
> > handle both SystemV and systemd systems.
>
> My situation is now solved. It's working as it should. I think Debian
> 9 is systemd by default, so I don't think it was a change from systemv
> to systemd. But it was definitely a change in programs used that
> required the change to "rsyslog-rotate".
That's right: AIUI buster is when rsyslog started using systemd to
rotate the logs, rather than the compatibility script that's still
present in /etc/init.d/ for non-systemd users. The decision is now
made in /usr/lib/rsyslog/rsyslog-rotate.
> > You rejected the new file, which is why it was instead written to
> > /etc/logrotate.d/rsyslog.dpkg-dist (which you could have safely
> > left or removed—it's harmless).
>
> Yes, I rejected the new file, causing the other file to be there. It
> would be nice if updates told what needed to be updated in the old
> file when updates are done.
If you reject the file, it falls to you to look at what changes were
made. All the system knows is that your file's message digest doesn't
match what dpkg expects as the old Debian version.
> > Effectively, your edit has merged the contents of both files,
> > whatever changes you made earlier before the Buster upgrade,
> > and the vital change that would have been made for you if
> > you'd accepted the new version.
>
> But If I had accepted the new file, it would probably have discarded the changes that I had made.
Yes. It's a while since I did this, but I'm almost certain that
your own version would be renamed as *.dpkg-old were you to accept
the new version.
> It would be nice if updates presented "old file", "new file", "combined file"; choice: (1), (2), (3).
(3) isn't really practicable, and you couldn't really set that
as Policy unless it could be more or less guaranteed to work.
To mis-quote Tolstoy, “Happy updates are all alike; every
unhappy update is unhappy in its own way.”
You could use patch to generate a .diff between your version and
its original, then apply the patch to the new Debian version.
Fine when it works, but there's no guarantee. It requires a
certain discipline when making any changes. So it's safer to
leave the choice of process to the system administrator.
Cheers,
David.
Reply to: