Lots of log lines when using `cron`, reported in logwatch

Rocky Linux General
1

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[1]: Started Session 100 of user sweh.
Aug  6 16:43:01 brains systemd[1]: session-100.scope: Succeeded.
Aug  6 16:44:01 brains systemd[1]: Started Session 101 of user sweh.
Aug  6 16:44:01 brains systemd[1]: session-101.scope: Succeeded.
Aug  6 16:45:01 brains systemd[1]: Started Session 102 of user sweh.
Aug  6 16:45:01 brains systemd[1]: 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 :slight_smile:

2

Hi,

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/

edit /etc/systemd/system/crond.service:

[Unit]
Description=Command Scheduler
After=auditd.service nss-user-lookup.target systemd-user-sessions.service time-sync.target ypbind.service autofs.service

[Service]
EnvironmentFile=/etc/sysconfig/crond
ExecStart=/usr/sbin/crond -n $CRONDARGS
ExecReload=/bin/kill -HUP $MAINPID
KillMode=process
Restart=on-failure
RestartSec=30s
StandardOutput=null
StandardError=null

[Install]
WantedBy=multi-user.target

StandardOutput=null
StandardError=null

Are the added entries.

systemd daemon-reload
systemctl restart crond

Thanks Tom.

3

Hmm, probably just session-.*.scope: Succeeded

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[1] 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?

4

Hi,

Sorry just to clarify these entries are in journalctl, rather than /var/log/messages ?

Thanks Tom.

5

They show in /var/log/messages and in journalctl -t systemd

6

Hi,

If Logwatch is monitoring journalctl, this may help:

Thanks Tom.

7

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.

8
9

Interesting!

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

Thanks!

1 Like