Red Hat Bugzilla – Bug 187334
crond ORPHAN (no passwd entry) on NIS+ system
Last modified: 2007-11-30 17:11:28 EST
Description of problem: This is exact duplicate of bug 146964 I filed over a year ago against RHEL-3. The bug is back on FC5. Version-Release number of selected component (if applicable): vixie-cron-4.1-54.FC5 How reproducible: always Steps to Reproduce: 1. Configure system with NIS+ 2. Login as an NIS user (not in local /etc/passwd) 3. Add crontab entry with "crontab -e" Actual results: Cron refuses to run the job: /var/log/cron Mar 29 15:58:06 dev3 crontab[8059]: (devtest) BEGIN EDIT (devtest) Mar 29 15:58:09 dev3 crontab[8059]: (devtest) END EDIT (devtest) Mar 29 15:59:01 dev3 crond[2302]: (devtest) ORPHAN (no passwd entry) Expected results: crond should run jobs for users for which getpwnam() returns a valid entry. Additional info: Why are we going in circles?
I cannot reproduce this problem . I created a cron job as a NIS only user (user not in /etc/passwd, only in NIS) with nsswitch.conf containing: 'passwd: nis files group: nis files ' The jobs for this NIS user ran fine. What do your nsswitch.conf passwd: and group: entries look like? Do you use nscd ? Sometimes, if the NIS server is down, or there is an interruption in network service, the network lookup for passwd or group for a crontab NIS user can fail; but when the service comes back up, the jobs will be loaded.
# Lgged in as NIS-only user "devtest" $ egrep '^(passwd|group)' /etc/nsswitch.conf passwd: files nis group: files nis $ date && ypcat passwd | grep devtest && echo "* * * * * /bin/echo here" > /tmp/cron.$$ && crontab /tmp/cron.$$ && sleep 60 && sudo grep devtest /var/log/cron | tail -2 Thu Mar 30 12:13:14 PST 2006 devtest:****:249:100:DevTest:/home/camel7/devtest:/usr/local/bin/bash Mar 30 12:13:14 dev3 crontab[31531]: (devtest) REPLACE (devtest) Mar 30 12:14:01 dev3 crond[2302]: (devtest) ORPHAN (no passwd entry) # crypted password above replaced with "****" # repeat Thu Mar 30 12:15:52 PST 2006 devtest:****:249:100:DevTest:/home/camel7/devtest:/usr/local/bin/bash Mar 30 12:15:52 dev3 crontab[31549]: (devtest) REPLACE (devtest) Mar 30 12:16:01 dev3 crond[2302]: (devtest) ORPHAN (no passwd entry) > Do you use nscd ? I was. However neither '/etc/rc.d/init.d/nscd restart' nor 'stop' appears to have any effect. Logging in with ssh instead of rlogin has no effect. Restarting crond ... CURES it! So (apparently) crond starts before the "firstboot" screen comes up (the one where I configure local users and/or NIS). After I add NIS users, crond is not restarted, and refuses to run NIS-only jobs until restart/reboot. Perhaps the system-config-authentication should restart crond? Feel free to close this bug or reassign it to the authconfig (which is authconfig-gtk-5.2.2-1). Thanks,
It could also be argued that crond should not cache valid/invalid user info and should not require a restart when nsswitch.conf is re-configured
Aha! Thanks for the detective work. This is actually a glibc issue, as noted in man nsswitch.conf(5): " NOTES Within each process that uses nsswitch.conf, the entire file is read only once; if the file is later changed, the process will continue using the old configuration. " Sorry, I didn't realize you had just configured NIS on an existing system with an already running crond - then this problem is to be expected, and restarting crond should indeed cure the problem. I guess system-config-authentication should prompt you to reboot after changing the nsswitch.conf - many other daemons will be in the same boat as crond, eg. sshd - I'll add the system-config-authentication maintainer to this bug report - perhaps we should make system-config-authentication at least warn users of this issue when nsswitch.conf is changed.
I'm a little bit suspicious about the note above because as I've tested it sshd really avoids this problem somehow. And I don't think there is any special measure for this problem in the sshd sources. But it is not a problem to add the crond to the list of the services which are restarted from authconfig after firstboot is run. There are already many services which are restarted this way.
In a private message I said: "sshd does not appear to be affected, and was started 1 second before cron ..." What I missed is that sshd was restarted 3 minutes later (probably after authconfig finished). So sshd probably already is in the authconfigs' list of services to restart; and crond should be addred to that list.
It is already on the list. However I've tested it independently on authconfig and it still didn't seem to be affected.