Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 187334 - crond ORPHAN (no passwd entry) on NIS+ system
crond ORPHAN (no passwd entry) on NIS+ system
Product: Fedora
Classification: Fedora
Component: vixie-cron (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jason Vas Dias
Brock Organ
Depends On:
  Show dependency treegraph
Reported: 2006-03-30 00:50 EST by Paul Pluzhnikov
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-03-30 19:04:27 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Paul Pluzhnikov 2006-03-30 00:50:14 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):

How reproducible:

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:
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?
Comment 1 Jason Vas Dias 2006-03-30 11:21:38 EST
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.
Comment 2 Paul Pluzhnikov 2006-03-30 15:35:48 EST
# 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[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
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

Comment 3 Paul Pluzhnikov 2006-03-30 18:56:22 EST
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 
Comment 4 Jason Vas Dias 2006-03-30 19:04:27 EST
Aha! Thanks for the detective work. This is actually a glibc issue, as noted in
man nsswitch.conf(5):
     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.
Comment 5 Tomas Mraz 2006-03-31 00:14:26 EST
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.
Comment 6 Paul Pluzhnikov 2006-03-31 09:09:33 EST
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.
Comment 7 Tomas Mraz 2006-03-31 10:56:33 EST
It is already on the list. However I've tested it independently on authconfig
and it still didn't seem to be affected.

Note You need to log in before you can comment on or make changes to this bug.