Red Hat Bugzilla – Bug 66711
nsswitch.conf=nis causes chown to take 2 min during kickstart post-install
Last modified: 2007-04-18 12:43:10 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9) Gecko/20020513
Description of problem:
I am running a kick-started, NFS install of RH 7.3. My "%post"
post-installation script mounts an NFS volume, (with the "-o nolock" option,)
and runs a set of configuration scripts that do everything from installing
additional RPMS to installing or patching config files.
At some point (this also appeared in RH7.2,) I realized that my unattended,
kickstart installations were taking much longer than they should have. The post
installation script, rather than taking a couple of minutes to run, was taking
nearly half an hour.
I have finally tracked down what the big slowdown is. After changing the
nsswitch.conf file to use NIS, everytime I execute a "chown <directory>" command
in my post-install scripts, the system waits exactly 120 seconds before
completing the command. Similarly, anywhere I execute a "/usr/bin/install
--directory --owner= --group=" command, it takes exactly 120 seconds to complete.
This seems to be some kind of timeout associated with NIS, even though the uids
and guids involved can be resolved completely by /etc/passwd and group files.
This phenomenon can be observed on the VT2 debugging shell during installation
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. NFS install of RH 7.3, with kickstart. Details of kickstart seem unimportant.
2. After RPM installation completes, go to VT2
3. chroot to /mnt/sysimage
4. Replace all "nisplus" in /etc/nsswitch.conf with "nis".
5. date; /usr/bin/install --verbose --directory --owner=4 --group=7 --mode=700
5. mkdir -p /var/spool/lpd/foo; date; chown 4:7 /var/spool/lpd/foo; date
Thu Jun 13 19:17:09 EST 2002
/usr/bin/install: creating directory `/var/spool/lpd/foo'
Thu Jun 13 19:19:09 EST 2002
Duration is exactly 120 seconds.
Expected Results: A simple "chown" of a directory should take place just about
instantaneously, not take two minutes.
I have duplicated this problem in both RH7.2 and RH7.3, on a variety of
Chowning and installing files instead of directories does not display this
problem. This problem manifests itself only during the installation process --
once the machine reboots for the first time, everything seems to be normal.
The lines in /etc/nsswitch.conf that I change are these:
the default entries
passwd: files nisplus
shadow: files nisplus
group: files nisplus
are changed to
passwd: files nis
shadow: files nis
group: files nis
Now, I realize that this change to the nsswitch.conf file causes glibc to wish
to perform NIS lookups from an NIS server that won't be available until after
the install, but I am providing numeric uids and gids here -- there really
shouldn't be anything to lookup.
I'm sure there is some subtle reason why it waits two minutes for a nonexistent
NIS server, but doesn't seem to mind a nonexistent nisplus server, but this
really isn't the behavior I expected.
The workaround is easy enough -- don't change nsswitch.conf until everything
else in the post-installation script is done. But the implication is clear that
setting the line to
passwd: files nis
does not cause uid resolution to stop with "files" even if the answer is present
in said files. It waits on some kind of connection with the NIS server.
IMO this is the intended behavior when the NIS server isn't available.
With NIS, there's nothing that prevents you from creating a user "4" with user
ID 1234, and that's what's being looked up. 4 == the user ID is used as a
fallback when the user "4" doesn't exist.