Cron not running due to SELinux

[ukoda]

On a new CentOS 8 server I am setting up to replace an old CentOS 6 server I have noticed the cron tasks have stop running. If I restart cron I see this in cron log:

Code: Select all

Oct  5 15:10:36 ichi crond[340246]: (CRON) STARTUP (1.5.2)
Oct  5 15:10:36 ichi crond[340246]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 98% if used.)
Oct  5 15:10:36 ichi crond[340246]: ((null)) No SELinux security context (/etc/crontab)
Oct  5 15:10:36 ichi crond[340246]: (root) FAILED (loading cron table)
Oct  5 15:10:36 ichi crond[340246]: ((null)) No SELinux security context (/etc/cron.d/0hourly)
Oct  5 15:10:36 ichi crond[340246]: (root) FAILED (loading cron table)
Oct  5 15:10:36 ichi crond[340246]: ((null)) No SELinux security context (/etc/cron.d/raid-check)
Oct  5 15:10:36 ichi crond[340246]: (root) FAILED (loading cron table)
Oct  5 15:10:36 ichi crond[340246]: (CRON) INFO (running with inotify support)
Oct  5 15:10:36 ichi crond[340246]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

The file /etc/crontab is currently:

Code: Select all

-rw-r--r--. 1 root root system_u:object_r:system_cron_spool_t:s0 516 Aug 19 14:52 crontab

/etc/cron.hourly is:

Code: Select all

[root@ichi etc]# ls -laZ cron.hourly/
total 24
drwxr-xr-x.   2 root root system_u:object_r:bin_t:s0   70 Oct  5 09:49 .
drwxr-xr-x. 151 root root system_u:object_r:etc_t:s0 8192 Oct  3 14:10 ..
-rwxr-xr-x.   1 root root system_u:object_r:bin_t:s0  575 Nov  9  2019 0anacron

I have spent several hours looking around for a solution but nothing I have found seems to help, so I'm open to suggestions.

[lightman47]

I'd try restorecon /etc/crontab if it were me. The entries in my cron.hourly look the same as yours.

[ukoda]

Thanks for the suggestion. Unfortunately I had already tried that with no change:

Code: Select all

[root@ichi etc]# ls -laZ /etc/crontab 
-rw-r--r--. 1 root root system_u:object_r:system_cron_spool_t:s0 516 Aug 19 14:52 /etc/crontab
[root@ichi etc]# restorecon /etc//crontab 
[root@ichi etc]# ls -laZ /etc/crontab 
-rw-r--r--. 1 root root system_u:object_r:system_cron_spool_t:s0 516 Aug 19 14:52 /etc/crontab
[root@ichi etc]# systemctl restart crond
[root@ichi etc]# tail /var/log/cron
Oct  6 00:32:21 ichi crond[409264]: (CRON) STARTUP (1.5.2)
Oct  6 00:32:21 ichi crond[409264]: (CRON) INFO (RANDOM_DELAY will be scaled with factor 88% if used.)
Oct  6 00:32:21 ichi crond[409264]: ((null)) No SELinux security context (/etc/crontab)
Oct  6 00:32:21 ichi crond[409264]: (root) FAILED (loading cron table)
Oct  6 00:32:21 ichi crond[409264]: ((null)) No SELinux security context (/etc/cron.d/0hourly)
Oct  6 00:32:21 ichi crond[409264]: (root) FAILED (loading cron table)
Oct  6 00:32:21 ichi crond[409264]: ((null)) No SELinux security context (/etc/cron.d/raid-check)
Oct  6 00:32:21 ichi crond[409264]: (root) FAILED (loading cron table)
Oct  6 00:32:21 ichi crond[409264]: (CRON) INFO (running with inotify support)
Oct  6 00:32:21 ichi crond[409264]: (CRON) INFO (@reboot jobs will be run at computer's startup.)

[lightman47]

Found this, seemed to be a problem in Fedora for a while:

https://bugzilla.redhat.com/show_bug.cgi?id=1862823

Perhaps some useful info here.

[ukoda]

Yes, I did see that one during my research. I had trouble following the finer points but my takeaway from it was someone broke things with a package update and it was subsequently fixed and there was no user steps to fix except to wait for the fix to flow downstream. I though if it was that also affecting CentOS then other people were likely to have seen the issue but a search here before posting suggested it that no one else was having problems.

Maybe it will come right with some future package update. To be honest my current plan is to write a bash script that does what cron would normally do until a fix comes to my attention as I have bigger fish to fry such as migrating my email services from my old server before it dies.

[TrevorH]

What's the output from rpm -V cronie ?

[ukoda]

Nothing:

Code: Select all

[root@ichi etc]# rpm -V cronie
[root@ichi etc]#

The command "rpm -qi cronie" returns:

Code: Select all

[root@ichi etc]# rpm -qi cronie
Name        : cronie
Version     : 1.5.2
Release     : 4.el8
Architecture: x86_64
Install Date: Wed 20 May 2020 15:07:52 NZST
Group       : System Environment/Base
Size        : 324627
License     : MIT and BSD and ISC and GPLv2+
Signature   : RSA/SHA256, Thu 05 Dec 2019 11:57:46 NZDT, Key ID 05b555b38483c65d
Source RPM  : cronie-1.5.2-4.el8.src.rpm
Build Date  : Sat 09 Nov 2019 05:47:45 NZDT
Build Host  : x86-01.mbox.centos.org
Relocations : (not relocatable)
Packager    : CentOS Buildsys <bugs@centos.org>
Vendor      : CentOS
URL         : https://github.com/cronie-crond/cronie
Summary     : Cron daemon for executing programs at set times
Description :
Cronie contains the standard UNIX daemon crond that runs specified programs at
scheduled times and related tools. It is a fork of the original vixie-cron and
has security and configuration enhancements like the ability to use pam and
SELinux.
[root@ichi etc]#

And some general system information for completeness:

Code: Select all

[root@ichi etc]# cat os-release 
NAME="CentOS Stream"
VERSION="8"
ID="centos"
ID_LIKE="rhel fedora"
VERSION_ID="8"
PLATFORM_ID="platform:el8"
PRETTY_NAME="CentOS Stream 8"
ANSI_COLOR="0;31"
CPE_NAME="cpe:/o:centos:centos:8"
HOME_URL="https://centos.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_SUPPORT_PRODUCT="Red Hat Enterprise Linux 8"
REDHAT_SUPPORT_PRODUCT_VERSION="CentOS Stream"
[root@ichi etc]# uname -a
Linux ichi.--redacted-- 4.18.0-240.el8.x86_64 #1 SMP Fri Sep 25 19:48:47 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux
[root@ichi etc]#

[TrevorH]

That's Stream. Quite an important bit of info that you're running the RHEL 8.next alpha code not CentOS Linux 8.

[ukoda]

Ugh, it sounds like I have misunderstood the intent of CentOS Stream. My job is not fulltime Linux servers, they are just a tool I use. Changing from one release to the next is a major pain point for me, I'm looking for evolution of my servers, not revelation. Ideally I should be telling you what date I last did a "dnf update", not what version am I running. The difference between Stream and regular releases may not have been spelt out in enough detail for people like me to chose correctly. I was looking for a version of CentOS that is effectively a rolling release so I could avoid all the pain of moving version every few years. However your comment makes sound like I have instead chosen leading edge unstable unsupported software. In which case it should have been named "CentOS Alpha" not "CentOS Stream".

If that is the case it sounds like I will have format the HDD and start over again with the regular version and just accept that running a CentOS server implies periodic pain points.