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 > <[email protected]> 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 [email protected]
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
