Crond[501]: (CRON) OPENDIR FAILED (/etc/cron.d): No such file or directory

I run:

journalctl -a

My system is spewing out millions of these cron failures.
I can’t see any info on what is triggering these crons.
Where would I even start to find the cause of these that may lead me to rectification solutions?

crond[501]: (CRON) OPENDIR FAILED (/etc/cron.d): No such file or directory

crond[501]: (CRON) STAT FAILED (/etc/cron.d): No such file or directory

cron is outdated. We provide it as an optional feature for those who know how to use it and can configure it properly. It does not get installed by default.

If you don’t know cron, I would suggest that you uninstall it (sudo swupd bundle-remove cronie). systemd timer units are the way to go, and this is what clearlinux uses by default.

Documentation to learn more about systemd.timers
https://www.freedesktop.org/software/systemd/man/systemd.timer.html

You can also peek at swupd-update.timer with systemctl cat swupd-update.timer for an example of one.

systemctl cat swupd-update.timer
# Unit swupd-update.timer is masked.

Ok, maybe that is not a good example if you have disabled autoupdate :slight_smile:. You can look at systemctl list-timers and pick some other one to investigate.

1 Like

I will investigate.

What I don’t get is I have only 1 cronjob that I know of

/var/spool/cron/root

0 3 * * * sudo rsync -axHAWXS --numeric-ids --info=progress2 --delete --exclude={/mnt/*,/media/*,/lost+found} / /mnt >> /tmp/rsync.log

yet that is set to run at 3am every day.

The errors mentioned above, there are thousands of them at many hours all through the day. I don’t have /etc/cron.d

Errors give no info as to what exactly the cron task is and where is it invoked from. I am certain cron binary was already on this system before installing cronie the other day.

Our bundles have all the data, and therefore all the evidence. The cronie package is only available in the cronie bundle, and that is not part of any dependency or include. It doesn’t matter though, the error is still pretty annoying.

[quote=“ketonik, post:6, topic:1620”]
I don’t have /etc/cron.d[/quote]

Entirely correct. That would be against our own packaging rules.

This isn’t a clearlinux problem. Logs are semi-anonymous and applications can spoof log messages. However, fortunately, you have really good evidence what software is making the error, because crond[501] is stating exactly which PID and process name is doing this.

With that information, you can run systemd-cgls and see what unit/service this process belongs to. For instance, if I was looking on my system for something logging something like this:

NetworkManager[490]: <info>  [1568667028.7461] agent-m...

Then I can track it down through systemd-cgls and see:

  ├─NetworkManager.service
  │ └─490 /usr/bin/NetworkManager --no-daemon

Then a simple systemctl status NetworkManager.service tells me the rest of the information.

BTW, a simple sudo mkdir /etc/cron.d will likely make the error disappear.

FWIW, man systemd.timer has the docs on timers.

Thanks ahkok.

systemd-cgls

 ├─cronie.service
  │ └─501 /usr/bin/crond -n

systemctl status cronie.service

 cronie.service - Periodic Command Scheduler
   Loaded: loaded (/usr/lib/systemd/system/cronie.service; enabled; vendor preset: disabled)
   Active: active (running) since Mon 2019-09-16 13:52:34 AEST; 22h ago
 Main PID: 501 (crond)
    Tasks: 1 (limit: 4915)
   Memory: 9.8G
   CGroup: /system.slice/cronie.service
           └─501 /usr/bin/crond -n

Indeed it is cronie, great information thanks so much, thank goodness it is not my PHP cron jobs.

I will for now:

mkdir /etc/cron.d

Inspect the log and see if this resolves while reading about systemd.timer hopefully i can discover this can run my rsync command at time desired then i’ll remove cronie.

For those who don’t like systemd timers, there’s Jobber :

https://dshearer.github.io/jobber

Along with the functionality of cron, Jobber also provides:

  • Job execution history: you can see what jobs have recently run, and whether they succeeded or failed.

  • Sophisticated error handling: you can control whether and when a job is run again after it fails. For example, after an initial failure of a job, Jobber can schedule future runs using an exponential backoff algorithm.

  • Sophisticated error reporting: you can control whether Jobber notifies you about each failed run, or only about jobs that have been disabled due to repeated failures.

Syntax and examples :
https://dshearer.github.io/jobber/doc/v1.4/

1 Like