Bug 187334

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.