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! The rules for rsyslog are actually provided by rsyslog not logcheck-database so this bug should be against rsyslog -- however, im not sure rsyslog produces those messages about HUP any more so maybe it should be closed rather than reassigned? I do see the one about the unix socket but a) i wonder if that's a bug rather that should be hidden? 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 (apologies if i am wrong on this - i dont usually have rsyslog installed, but ve been running it in a container for testing some upcoming changes to logcheck and i don't see either of the messages above despite running for several days).
