Knowledge Base:Cron fails to load in root crontab with message ENTRYPOINT FAILED

From Gentoo Wiki
Jump to:navigation Jump to:search


Inside the cron.log file the following error message can be found:

FILE cron.logError message regarding ENTRYPOINT on root crontab
Dec 27 14:11:36 hpl cron[2258]: (root) ENTRYPOINT FAILED (crontabs/root)

Also notice that the root users' crontab is not used.


This article is applicable on Gentoo Linux systems with a selinux profile:

root #eselect profile show
Current /etc/make.profile symlink:

The user also has ubac set in the system's USE flags:

root #emerge --info | grep ^USE | grep ubac
USE="... ubac ..."

Finally, the users' installed cron system is sys-process/vixie-cron:

root #qlist -I vixie-cron


When sys-process/vixie-cron wants to execute a users' crontab (including the root user), it first checks the SELinux user owner of the crontab file to make sure that it is safe to execute. But if some user other than root created the root crontab as a regular user (with su or sudo) then the ownership of the file will, SELinux-wise, still be that of the user that created it (most likely staff_u). Hence, cron (well, actually SELinux) refuses to load in the file.

With USE="ubac" set, access from specific domains towards resources (like files) are only allowed if the source context owner is the same as the target, or when sysadm_t is involved (this domain is exempt from the User Based Access Controls).


Verify that the root user file is indeed not owned by the root SELinux user:

root #ls -Z /var/spool/cron/crontabs/root
staff_u:object_r:user_cron_spool_t  /var/spool/cron/crontabs/root

Correct the SELinux owner of the file:

root #chcon -u root /var/spool/cron/crontabs/root

Another solution would be to disable user-based access control by setting USE="-ubac", but this reduces one of the access controls in place and as thus not recommended.

See also