reassign 1015201 rsyslog
thanks
Hello Richard,
Am Sat, Apr 27, 2024 at 07:11:40PM +0100 schrieb Richard Lewis:
> On Sun, 17 Jul 2022 17:28:11 +0100 Richard Lewis
> <richard.lewis.deb...@googlemail.com> wrote:
> > > The pattern for rsyslogd can be improved. Please add the following
> > > line:
> > >
> > > imuxsock: Acquired UNIX socket '/run/systemd/journal/syslog' \(fd 3\)
> > > from systemd. \[v8.2206.0\]
> > >
> > > You might want to generalize the fd (on my system it is always fd 3,
> > > but I don't know if this is general) and possibly the version number;
> > > ideally this would remain in sync to whatever is in testing.
> >
> > I have the following rules in etc/logcheck/ignore.d.server/local-rsyslog
> >
> > ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ systemd\[1\]: rsyslog\.service:
> > Sent signal SIGHUP to main process [0-9]+ \(rsyslogd\) on client
> > request\.$
> > ^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd\[[0-9]+\]: \[origin
> > software="rsyslogd" swVersion="[0-9.]+" x-pid="[0-9]+"
> > x-info="https://www.rsyslog.com"\] rsyslogd was HUPed$
> >
> > so you might like to add those too. (i believe these are caused by
> > logrotate via /usr/lib/rsyslog/rsyslog-rotate , the latter being part
> > of rsyslog). they are relevant to bullseye systems
>
> Hi Helge. Apologies no-one has replied to this bug report for 2 years
> and that this response isnt going to be what you want!
Thanks for taking care of it anyhow, I noticed that it is not worth
reporting improvements to logcheck proper.
> The rules for rsyslog are actually provided by rsyslog not
> logcheck-database so this bug should be against rsyslog --
Ok, I reassign this to rsyslogd
> however, im not sure rsyslog produces those messages about HUP any
> more so maybe it should be closed rather than reassigned?
Well, it still produces it on my (stable) system:
syslog:2024-04-29T09:20:13.401257+02:00 twentytwo rsyslogd: imuxsock: Acquired
UNIX socket '/run/systemd/journal/syslog' (fd 3) from systemd. [v8.2302.0]
> I do see the one about the unix socket but
> a) i wonder if that's a bug rather that should be hidden?
I have no idea. I did not notice any problem and I read it as a status
message (I don't need to see regularly).
> b) I also think i only see it "startup" (ie only produced when the
> system boots / service starts):
> debian usually doesnt add rules to filter startup messages as it tends
> to add a lot of rules
Indeed, startup rules are quite helpful, because then I see what was
*different* during startup, i.e. if something got wrong. For servers,
this is not very useful, but for workstatins it is. Btw., the current
rules also deal with startup:
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ kernel: imklog [0-9.]+, log source =
/proc/kmsg started.$
…
^\w{3} [ :0-9]{11} [._[:alnum:]-]+ rsyslogd: \[origin software="rsyslogd"
swVersion="[0-9.]+" x-pid="[0-9]+" x-info="https://www.rsyslog.com"\] start$
…
Greetings
Helge
--
Dr. Helge Kreutzmann deb...@helgefjell.de
Dipl.-Phys. http://www.helgefjell.de/debian.php
64bit GNU powered gpg signed mail preferred
Help keep free software "libre": http://www.ffii.de/
signature.asc
Description: PGP signature
