Description of problem: If cron ever orphans a crontab (typically due to a temporary NSS lookup failure, ie. NIS or LDAP servers unreachable) during startup or following a crontab edit, that crontab will never be reloaded until the crontab is edited again or cron is restarted. This is hardly a new problem -- indeed bug 9405 comment 0 covers it nicely, though the solution that was implemented didn't address the general case. Version-Release number of selected component (if applicable): vixie-cron-4.1-66.1.el5 How reproducible: Make a nss_ldap system's LDAP server unreachable. Edit a crontab for a non-local user. Actual results: Jun 26 17:33:01 app101 crontab[4788]: (oliver) REPLACE (oliver) Jun 26 17:34:01 app101 crond[4164]: nss_ldap: could not search LDAP server - Server is unavailable Jun 26 17:34:01 app101 crond[4164]: (oliver) ORPHAN (no passwd entry) Expected results: crond should periodically revisit orphans so that Oliver can continue to submit his automated request for more porridge.
The impact of this is of course further compounded since without bug 241067 (ignoring a bug 187334 condition) there's no chance of Oliver discovering his crontab's status.
This request was evaluated by Red Hat Product Management for inclusion, but this component is not scheduled to be updated in the current Red Hat Enterprise Linux release. If you would like this request to be reviewed for the next minor release, ask your support representative to set the next rhel-x.y flag to "?".
Could PM clarify comment 2? This is a bug report, not a feature request and without a fix Oliver is again being driven into the company of Jack Dawkins and Charlie Bates.
I'm sorry, but it's late for inclusion. I can only work on fix for next release.
How is this now INSUFFICIENT_DATA? What additional data is needed between comment 2 and now? Is there another bug I'm unaware of that obviated the need to "fix for next release" in comment 4?
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
It was fixed by upstream commit 8b407876f276f96914111bd9954f21f627db7b11
This is much more simple procedure and not requiring any LDAP server to be setup at all: 1. useradd testuser 2. su - testuser 3. add cron job for the testuser using crontab -e 4. (see that the cron job runs fine) 5. service crond stop 6. userdel testuser 7. service crond start 8. (see that there is orphan log message from the testuser job) 9. useradd testuser [assumed that the same uid/gid is obtained] 9. (see that the jobs for testuser now run again)
(In reply to comment #32) > This is much more simple procedure and not requiring any LDAP server to be > setup at all: THANKS MUCH! > > 1. useradd testuser > 2. su - testuser > 3. add cron job for the testuser using crontab -e > 4. (see that the cron job runs fine) > 5. service crond stop > 6. userdel testuser > 7. service crond start > 8. (see that there is orphan log message from the testuser job) > 9. useradd testuser [assumed that the same uid/gid is obtained] > 9. (see that the jobs for testuser now run again) I followed your procedure (only s/testuser/newtestuser/) and find that after step 9 cron does not run again jobs for newtestuser. vixie-cron-4.1-79.el5: FYI step 9: id newtestuser was the same (503) like before (step 2) There is log after the step 8(crond start), and see error "(newtestuser) FSTAT FAILED" which was shown after adding newtestuser Oct 20 08:14:09 ibm-z10-30 crond[24333]: (CRON) STARTUP (V5.0) Oct 20 08:14:09 ibm-z10-30 crond[24333]: (bz654961-239364512) ORPHAN (no passwd entry) Oct 20 08:14:09 ibm-z10-30 crond[24333]: (newtestuser) ORPHAN (no passwd entry) Oct 20 08:14:09 ibm-z10-30 crond[24333]: (cron-pam-test) ORPHAN (no passwd entry) Oct 20 08:14:09 ibm-z10-30 crond[24333]: (bz654961-300317665) ORPHAN (no passwd entry) Oct 20 08:14:09 ibm-z10-30 crond[24333]: (CRON) @reboot jobs will be run at computer's startup. () Oct 20 08:15:01 ibm-z10-30 crond[24336]: (CRON) chdir(HOME) failed: (No such file or directory) Oct 20 08:15:01 ibm-z10-30 crond[24337]: (mrX) CMD (/bin/cat ~/testfile.txt > /tmp/out-cat) Oct 20 08:15:01 ibm-z10-30 crond[24338]: (CRON) chdir(HOME) failed: (No such file or directory) Oct 20 08:15:01 ibm-z10-30 crond[24339]: (mrX) CMD (/bin/ls ~ > /tmp/out-ls) Oct 20 08:15:02 ibm-z10-30 crond[24336]: (mrX) MAIL (mailed 60 bytes of output but got status 0x0043 ) Oct 20 08:15:02 ibm-z10-30 crond[24338]: (mrX) MAIL (mailed 46 bytes of output but got status 0x0043 ) Oct 20 08:15:39 ibm-z10-30 crontab[24356]: (root) LIST (newtestuser) Oct 20 08:16:01 ibm-z10-30 crond[24333]: (newtestuser) FSTAT FAILED (cron/newtestuser) Oct 20 08:16:01 ibm-z10-30 crond[24358]: (CRON) chdir(HOME) failed: (No such file or directory) Oct 20 08:16:01 ibm-z10-30 crond[24357]: (CRON) chdir(HOME) failed: (No such file or directory) Oct 20 08:16:01 ibm-z10-30 crond[24360]: (mrX) CMD (/bin/cat ~/testfile.txt > /tmp/out-cat) Oct 20 08:16:01 ibm-z10-30 crond[24359]: (mrX) CMD (/bin/ls ~ > /tmp/out-ls) Oct 20 08:16:01 ibm-z10-30 crond[24357]: (mrX) MAIL (mailed 60 bytes of output but got status 0x0043 ) Oct 20 08:16:01 ibm-z10-30 crond[24358]: (mrX) MAIL (mailed 46 bytes of output but got status 0x0043 ) after the step 9, there is cron entry for newtestuser: # crontab -u newtestuser -l * * * * * /bin/echo hello >> /tmp/newhello
Ok, I had an error in backport. With new build according to test case in #32 you should see: Oct 20 15:49:01 rhel-5-marcela crond[5497]: (bob) CMD (touch /tmp/bob) Oct 20 15:50:06 rhel-5-marcela crond[5690]: (CRON) STARTUP (V5.0) Oct 20 15:50:06 rhel-5-marcela crond[5690]: (bob) ORPHAN (no passwd entry) Add bob back with same id. Oct 20 15:52:01 rhel-5-marcela crond[5764]: (bob) CMD (touch /tmp/bob) Oct 20 15:53:01 rhel-5-marcela crond[5768]: (bob) CMD (touch /tmp/bob)
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. http://rhn.redhat.com/errata/RHSA-2012-0304.html