I have a cronjob for my user:
% crontab -l
# Keep HE tunnel alive; kludge
* * * * * ping6 -c2 ipv6.he.net > /dev/null 2>&1
This results in log messages being generated; two per minute
Aug 6 16:43:01 brains systemd: Started Session 100 of user sweh.
Aug 6 16:43:01 brains systemd: session-100.scope: Succeeded.
Aug 6 16:44:01 brains systemd: Started Session 101 of user sweh.
Aug 6 16:44:01 brains systemd: session-101.scope: Succeeded.
Aug 6 16:45:01 brains systemd: Started Session 102 of user sweh.
Aug 6 16:45:01 brains systemd: session-102.scope: Succeeded.
That’s not too bad. The problem is
logwatch doesn’t know how to handle them, so my daily report is full of noise:
session-100.scope: Succeeded.: 1 Time(s)
session-101.scope: Succeeded.: 1 Time(s)
session-102.scope: Succeeded.: 1 Time(s)
session-103.scope: Succeeded.: 1 Time(s)
session-104.scope: Succeeded.: 1 Time(s)
session-105.scope: Succeeded.: 1 Time(s)
Obviously 1440 lines of noise is not useful
either add something like this too logwatches’s ignore.conf:
session-*.scope: Succeeded.: 1 Time\(s\)
or you can silence cron altogether which is now started by systemd:
cp /lib/systemd/system/crond.service /etc/systemd/system/
After=auditd.service nss-user-lookup.target systemd-user-sessions.service time-sync.target ypbind.service autofs.service
ExecStart=/usr/sbin/crond -n $CRONDARGS
ExecReload=/bin/kill -HUP $MAINPID
Are the added entries.
systemctl restart crond
Hmm, probably just
Hmm, is this
cron outputting the lines, or
systemd itself? Typically (at least on CentOS 7) stdout/stderr from an app is tagged with the executable file name. In this case the entry is tagged with
systemd which makes me think it’s not the cron process doing the output.
This only occurs if a non-root user has a cron job, so (first guess)
pam-systemd talking to the
systemd daemon which is then outputting data?
Sorry just to clarify these entries are in journalctl, rather than /var/log/messages ?
They show in
/var/log/messages and in
journalctl -t systemd
If Logwatch is monitoring journalctl, this may help:
The annoying lines don’t show up if I select the unit
journalctl -u crond (although the other log messages do) , which further makes me think it’s not cron that’s generating it, but the
systemd process itself.
It also shows up in the
systemd section of the logwatch output, and not the
cron section. Looking at
/usr/share/logwatch/default.conf/services/systemd.conf I see
Title = "Systemd"
# Which logfile group...
LogFile = messages
# Only give lines pertaining to the OMSA service...
*OnlyService = systemd
So it looks like it’s parsing
/var/log/messages and not the journal.
CentOS 7 doesn’t log this for crontab entries (my primary VM is C7 based and I have lots of jobs on it; approx 47 per hour), so the occasional login hadn’t bothered me with those Session entries.
I’m guessing this is an upstream cron change in RedHat that now causes cronjobs to be noisy. sigh