Bug 128843
| Summary: | root cron jobs exit immediately | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | G.Wolfe Woodbury <redwolfe> |
| Component: | vixie-cron | Assignee: | Jason Vas Dias <jvdias> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | rawhide | CC: | dgunchev, herrold, thomasz |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i586 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | FC5 | Doc Type: | Bug Fix |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2006-05-02 13:39:50 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Yes, it looks like an SELinux issue to me . It seems the 'pam_setcred' call is failing. Am investigating and will resolve as top priority. It was a PAM issue. You need to add the line: auth sufficient pam_rootok.so to the beginning of /etc/pam.d/crond . This is now in vixie-cron-4.1-6 . It's also best to install latest pam-0.77-53 . *** Bug 128915 has been marked as a duplicate of this bug. *** I have similar problem with FC3t1 - when I add new job to /etc/cron.d/myfile it never gets executed. If I add the same line to /etc/crontab it works fine. (vixie-cron-4.1-7) Do you have /etc/cron.allow and/or /etc/cron.deny files? Having /etc/cron.allow and/or /etc/cron.deny files makes no difference to this bug - if neither exist, only root can edit crontabs. Without the 'auth sufficient pam_rootok.so' line in /etc/pam.d/crond, no commands are executed at all, regardless of cron.allow/cron.deny. Ensure that the /etc/cron.d/myfile you created is owned by root and has mode 0600 - otherwise vixie-cron-4.1 will ignore it - this is default ISC cron 4.1 behavior. This one works:
echo '* * * * * root /usr/bin/logger "testing crond here every
minute"' > /etc/cron.d/myfile; chmod 600 /etc/cron.d/myfile; service
crond restart; tail -f /var/log/messages
This one does not:
echo '* * * * * root /usr/bin/logger "testing crond here every minute
1"' > /etc/cron.d/vsftpd; chmod 600 /etc/cron.d/vsftpd; service crond
restart; tail -f /var/log/messages
I have no /etc/cron.allow nor /etc/cron.deny, SELinux disabled,
kernel 2.6.7-1.503, pam-0.77-54, 2 x XEON at 2GHz, 2GB RAM. Things
always do work from /etc/crontab (for root and ordinary users)
and /etc/cron.d/myfile, but never from /etc/cron.d/vsftpd. I'll check
further...
I ran the exact command you gave, and it worked fine: echo '* * * * * root /usr/bin/logger "testing crond here every minute 1"' > /etc/cron.d/vsftpd; chmod 600 /etc/cron.d/vsftpd; service crond restart; tail -f /var/log/messages I then saw "testing crond here every minute 1" in the log. This was with vixie-cron-4.1-7. The only thing I can think of that could cause it to fail is if /etc/cron.d/vsftpd is a link - links are not allowed by ISC cron 4.1 as a security measure. It was a hardlink. It seems that crond now does not like symlinks, hardlinks and files owned/writable by someone else except root. |
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1) Gecko/20031114 Description of problem: root cron logs "Critical error - immediate termination" with no other indication of what the error is. Version-Release number of selected component (if applicable): vixie-cron-4.1-2 How reproducible: Always Steps to Reproduce: 1. clean install of rawhide 2004-07-29 2. examine /var/log/messages 3. Actual Results: /var/log/messages abstract (2 of about 100 entries) Jul 30 09:01:01 tembo crond(pam_unix)[19124]: session opened for user root by (uid=0) Jul 30 09:01:01 tembo crond[19124]: Critical error - immediate abort Expected Results: just a "session opened" notification Additional info: no indication in /var/log/cron of what the error is. This may be an SeLinux policy error, but there are no avc's that I can find.