2 minute crond job spamming journal

I have a cron job that has to run every two minutes. My systemd journal / log is getting spammed with this stuff. (names changed to protect the innocent) Can these messages be disabled?

Jul 31 15:12:01 myserver systemd[1]: Started Session c4906 of User myuser.
Jul 31 15:12:01 myserver cron[1776]: pam_unix(crond:session): session opened for user myuser by (uid=0)
Jul 31 15:12:01 myserver CRON[1777]: (myuser) CMD (blah blah)
Jul 31 15:12:03 myserver CRON[1776]: (myuser) CMDEND (blah blah)
Jul 31 15:12:03 myserver CRON[1776]: pam_unix(crond:session): session closed for user myuser
Jul 31 15:12:03 myserver systemd[1]: session-c4906.scope: Deactivated successfully.


Given that you seem to be either new or quiet – regardless –
Welcome to the openSUSE Forums.

Help for the ability to quieten down the amount that cron writes to Syslog and therefore also the systemd Journal may, possibly be found in the file ‘/etc/sysconfig/cron’ –

  • The parameters “SEND_OUTPUT_ON_NO_ERROR” and “SYSLOG_ON_NO_ERROR”.

This file is generated by the installation script of the “cronie” package which drops this configuration file into ‘/etc/sysconfig/’ based on the contents of the file ‘/usr/share/fillup-templates/sysconfig.cron’.

Here on Leap 15.5 – despite both those parameters being set to the value “no”, I still have the following entries in the systemd Journal:

 > sudo journalctl --no-hostname --unit cron --lines all
-- Boot 9a8f63186900468b8e9babefa71ae035 --
Jul 31 09:14:58 systemd[1]: Started Command Scheduler.
Jul 31 09:14:58 cron[2101]: (CRON) STARTUP (1.5.7)
Jul 31 09:14:58 cron[2101]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 27% if used.)
Jul 31 09:14:58 cron[2101]: (CRON) INFO (running with inotify support)
Jul 31 21:12:28 systemd[1]: Stopping Command Scheduler...
Jul 31 21:12:28 cron[2101]: (CRON) INFO (Shutting down)
Jul 31 21:12:28 systemd[1]: cron.service: Deactivated successfully.
Jul 31 21:12:28 systemd[1]: Stopped Command Scheduler.

Maybe the Stackoverflow answer is the better one:

 > sudo journalctl --no-hostname --unit cron --lines all _TRANSPORT=stdout
-- No entries --


cron logs each command it runs to syslog, and on your system the syslog ends up in the journal as well. As far as I’m aware, cron doesn’t have an option to disable that, but you can hide those messages by selecting only those journal messages received via stdout:

Thanks for the tip. Yes I know I can filter my journal entries using journalctl viewer. And I see that systemd developers philosophy is that the journal should accept everything even spammy cron job logs. My problem is that I have several servers feeding a remote syslog server and it is jammed up with these cron job logs.

I’ve managed to disable all of this logging now except for these session scope entries that look like this. Anyone know how I could suppress these:

systemd[1]: Started Session c6319 of User myuser.
systemd[1]: session-c6321.scope: Deactivated successfully.

Not a cron solution but you could try systemd timers.

What about describing how you did it for other users that may have the same question?

I do not think they can be disabled. These are generic messages emitted when unit job completes. The only way to prevent them is removing pam_systemd from cron PAM configuration.

systemd timers might be worth a try if logging can be subdued with those any better.

I managed to disable some logging by putting a conditional statement in /etc/pam.d/common-session. The statement basically skips all pam modules if the service is crond. This is not optimal because I think there might be unintended consequences! And it might not survive system updates…?

Anyway I found a better solution. I can keep these messages from going to the remote syslog by using a selector in /etc/rsyslog.d/remote.conf. I still have local journal spam on each server but at least I can keep it off of my syslog server.


There’s this long running Stack Exchange thread – latest addition, last year – cron versus systemd – <https://unix.stackexchange.com/questions/278564/cron-vs-systemd-timers>.

To be perfectly honest, I would agree with the last post where, the suggestion is made that, the decision to use either cron or systemd timers is a specific Use Case decision – either one or the other will be the better solution.