32 thoughts on - Exists Some Problem With Cronjobs Under CentOS7

• Did you have a question or error to point out? So far all I see is a correctly-running system.

• That’s the problem. There is no error but any cron job configured runs.. And this is the cuestion: why any cron job works?.

• It’s not clear what you’re asking. It would help if you replied with an example of a specific job that’s configured on your system, and explaining what it is doing that it should not, or what it is not doing that it should.

• Because systemwide cronjobs are installed in /etc/cron.* directories, not in root user cron file..

  Eero
  11.10.2015 7.39 ip. “C. L. Martinez” kirjoitti:

• For example: logwatch. Logwatch sends a daily email report about system’s health. I didn’t received this email from October 9th … and email configuration is ok.

• Thanks Eero. I know this. And I have tried to put some cron job in these directories to test … and nothing …

• So your problem is that cron jobs *DO NOT* run? Because every message you’ve sent so far has said that all jobs run.

• Yes. that is the problem … Sorry If I am not explained very well.

• What does /var/log/cron show? Are the jobs triggered, but you don’t get the expected output, or not triggered?

  If not triggered, you might want to show your crontab entries.

• Nothing … It is empty.

  Are the jobs triggered, but you don’t

  They are not triggered …

  I haven’t entries in conrtab’s users file at this moment, but I have done a test: * * * * * ls -la, and it is not triggered. But like I say before, installed system cronjobs like logwatch task are not triggered
  …

• What is returned if you issue the command:

  ps auxw | grep cron | grep -v grep

• Cron service is running:

  root 607 0.0 0.0 126304 1580 ? Ss 05:33 0:00
  /usr/sbin/crond -n

  And according to systemd, without problems:

  crond.service – Command Scheduler
  Loaded: loaded (/usr/lib/systemd/system/crond.service; enabled)
  Active: active (running) since Tue 2015-10-13 05:33:28 UTC; 8h ago Main PID: 607 (crond)
  CGroup: /system.slice/crond.service
  └─607 /usr/sbin/crond -n

• What is returned when you issue the commands:

  ps auxw | grep cron | grep -v grep

  systemctl status crond.service

• Do you have spamassassin running on the machine? I remember at one point, it was tagging the daily log messages as spam–this was awhile ago, I don’t remember the details or even if I fixed it or it was fixed by an update.

• No, it acts as a KVM server …

• Do you see anything helpful in the journal?

  run ‘journalctl _SYSTEMD_UNIT=crond.service’

  —
  Jonathan Billings

• Nop, because binary logs (using journalctl) are disabled in this host
  … But under /var/log/messages, there is no error …

• Might it be an idea to *not* disable logging?

  jh

• How did you disable journald?

• John Hodrien wrote:

  More to the point, perhaps, is there any way of recovering the entries that used to be in /var/log/ eg maillog?
  Does “journalctl -u sendmail” give exactly the same information?
  And what exactly is the status of syslog now?

• I’d say that crontab doesn’t actually prove that the job isn’t being triggered, it just proves there’s an email config/sending/something problem.

  if you change that to to something like

  * * * * * touch /var/tmp/cron-test-file

  does it create and keep changing the date on the file?

• If you haven’t reconfigured rsyslogd to use the uxsock source, disabling the journal will also disable the legacy logging system. If your cron log is actually empty, then you probably aren’t getting any logs at all.

  Start by turning your logging system back on. It’s the best source of data that you have at this point.

• Please note that /etc/cron.* files use a bit different syntax as normal crontab entries. First entry is user-id for cron job. It also requires strict permissions like (rw,r,r)

  Eero

  2015-10-13 17:39 GMT+03:00 C. L. Martinez :

  CentOS mailing list CentOS@CentOS.org https://lists.CentOS.org/mailman/listinfo/CentOS

• zep wrote:

  Dumb question: is there anything in /etc/cron.*?

  mark

• Correct Gordon, but I have enabled uxsock under rsyslog.conf to avoid the situation that you have explained.

  Thanks.

• Yes:

  -rw——- 1 root root 0 Jul 27 10:57 /etc/cron.deny
  -rw-r–r–. 1 root root 451 Jun 9 2014 /etc/crontab

  /etc/cron.d:
  total 28
  drwxr-xr-x. 2 root root 72 Sep 25 09:10 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..
  -rw-r–r– 1 root root 128 Jul 27 10:57 0hourly
  -rw-r–r– 1 root root 108 Mar 6 2015 raid-check
  -rw——- 1 root root 235 Mar 6 2015 sysstat
  -rw-r–r– 1 root root 187 Jan 27 2014 unbound-anchor

  /etc/cron.daily:
  total 40
  drwxr-xr-x. 2 root root 98 Sep 25 09:11 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..
  -rwxr-xr-x. 1 root root 434 Jun 10 2014 0logwatch
  -rwxr-xr-x. 1 root root 332 Mar 9 2015 0yum-daily.cron
  -rwx——. 1 root root 180 Jul 31 2013 logrotate
  -rwxr-xr-x. 1 root root 618 Mar 17 2014 man-db.cron

  /etc/cron.hourly:
  total 20
  drwxr-xr-x. 2 root root 44 Sep 25 09:10 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..
  -rwxr-xr-x 1 root root 392 Jul 27 10:57 0anacron
  -rwxr-xr-x. 1 root root 362 Mar 9 2015 0yum-hourly.cron

  /etc/cron.monthly:
  total 12
  drwxr-xr-x. 2 root root 6 Jun 9 2014 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..

  /etc/cron.weekly:
  total 12
  drwxr-xr-x. 2 root root 6 Jun 9 2014 . drwxr-xr-x. 115 root root 8192 Oct 14 09:19 ..

• Changing Storage’s option under /etc/systemd/journald.conf to none.

• Nothing … There is not cron-test-file under /var/tmp …

• Try it will /usr/bin/touch .. you may not have environment variables like PATH set.

• While Storage=none is supposed to forward on messages to syslog, it might be worth checking to see what process owns /dev/log:
  # lsof /dev/log

• Uhmm … that is not what I expect:

  lsof: WARNING: can’t stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
  Output information may be incomplete. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
  systemd 1 root 27u unix 0xffff880250ea0f00 0t0 1436 /dev/log systemd-j 263 root 5u unix 0xffff880250ea0f00 0t0 1436 /dev/log

  In theory, rsyslog is listenning to uxsock and imjournal:

  # rsyslog configuration file

  # For more information see /usr/share/doc/rsyslog-*/rsyslog_conf.html
  # If you experience problems, see http://www.rsyslog.com/doc/troubleshoot.html

  #### MODULES ####

  # The imjournal module bellow is now used as a message source instead of imuxsock.
  $ModLoad imuxsock # provides support for local system logging (e.g. via logger command)
  $ModLoad imjournal # provides access to the systemd journal
  #$ModLoad imklog # reads kernel messages (the same are read from journald)
  #$ModLoad immark # provides –MARK– message capability

• So, the obvious next step is to make sure journald isn’t holding that socket. That’s outside my experience, but I’d imagine that you can:

  systemctl disable systemd-journald.service systemctl stop systemd-journald.service

  Then you’ll need to restart rsyslog and verify that it owns /dev/log.

  Only one process can have a socket open at a time. Since journald holds
  /dev/log, rsyslog can’t, which is why your cron log is empty.

  There’s no real point in using imjournal if journald isn’t running.