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.
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:
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 :
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.