Most of us have a love-hate relationship with SELinux.
Human readable time stamps in audit.log
SELinux writes its audit log files using a cryptic format that includes a time stamp in the Unix time format of all things. (The number of seconds since the beginning of the year 1970 in UTC time). Here is how to convert the time stamp to a human readable format:
grep -i avc /var/log/audit/audit.log | ausearch -i
An SELinux bug can suppress cron jobs, here is the fix
In several versions of Fedora, crond is unable to access /etc/crontab courtesy of a bug in SELinux. The problem is well documented and it keeps popping up again and again. If your cron jobs keep failing silently unless run in permissive mode (not the idea!), there is an easy fix.
First you want to diagnose the issue. Create a cronjob that is easy on system resources so it can run every minute. With SELinux enforcing (setenforce 1), reload the configuration of crond:
systemctl restart crond
Check what keeps your cron job from executing:
journalctl -xe
You will see errors resembling this:
crond[12724]: ((null)) Unauthorized SELinux context=system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 file_context=unconfined_u:object_r:etc_t:s0 (/etc/crontab) crond[12724]: (root) FAILED (loading cron table)
Verify your suspicions:
ls -laZ /etc/crontab
Save the correct context in the SELinux configuration (this survives a system reboot):
semanage fcontext -a -t system_cron_spool_t "/etc/crontab"
Restore the SELinux file context from the now corrected configuration:
restorecon -RFv /etc/crontab
Your dummy cron job should be running now. Make sure you replace it with your intended cron jobs and reload (or restart) crond.
In Fedora 31, this problem has recurred with cronie-1.5.4-2.fc31.x86_64. The above fix doesn’t work here because the context on /etc/crontab and /etc/cron.d are already correct as system_u:object_r:system_cron_spool_t:s0
systemctl start crond.service results in these messages:
(CRON) STARTUP (1.5.4)
(CRON) INFO (RANDOM_DELAY will be scaled with factor 23% if used.)
((null)) No SELinux security context (/etc/crontab)
(root) FAILED (loading cron table)
((null)) No SELinux security context (/etc/cron.d/0hourly)
(root) FAILED (loading cron table)
This happened on both of my F31 machines when they updated cronie some time ago. It appears to me that crond is broken somehow and can’t read the contexts on those files, even though it is also running with the right context:
ps -eZ | grep cron
system_u:system_r:crond_t:s0-s0:c0.c1023 1579 ? 00:00:00 atd
system_u:system_r:crond_t:s0-s0:c0.c1023 37317 ? 00:00:00 crond
Can anyone help with this? My cron jobs are not running unless I go to permissive mode (not ideal). Thank you.