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):
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"
Cron refuses to run the job:
Mar 29 15:58:06 dev3 crontab: (devtest) BEGIN EDIT (devtest)
Mar 29 15:58:09 dev3 crontab: (devtest) END EDIT (devtest)
Mar 29 15:59:01 dev3 crond: (devtest) ORPHAN (no passwd entry)
crond should run jobs for users for which
getpwnam() returns a valid entry.
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
Mar 30 12:13:14 dev3 crontab: (devtest) REPLACE (devtest)
Mar 30 12:14:01 dev3 crond: (devtest) ORPHAN (no passwd entry)
# crypted password above replaced with "****"
Thu Mar 30 12:15:52 PST 2006
Mar 30 12:15:52 dev3 crontab: (devtest) REPLACE (devtest)
Mar 30 12:16:01 dev3 crond: (devtest) ORPHAN (no passwd entry)
> Do you use nscd ?
However neither '/etc/rc.d/init.d/nscd restart' nor 'stop' appears to have
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
Perhaps the system-config-authentication should restart crond?
Feel free to close this bug or reassign it to the authconfig (which is
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
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
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
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.