Bug 66711 - nsswitch.conf=nis causes chown to take 2 min during kickstart post-install
nsswitch.conf=nis causes chown to take 2 min during kickstart post-install
Product: Red Hat Linux
Classification: Retired
Component: fileutils (Show other bugs)
i386 Linux
medium Severity low
: ---
: ---
Assigned To: wdovlrrw
Aaron Brown
Depends On:
  Show dependency treegraph
Reported: 2002-06-13 22:03 EDT by Dennis Brylow
Modified: 2007-04-18 12:43 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-06-13 22:03:44 EDT
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 Dennis Brylow 2002-06-13 22:03:38 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
as well.

Version-Release number of selected component (if applicable):
fileutils-4.1-10, glibc-2.2.5-34

How reproducible:

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
/var/spool/lpd/foo; date


5.  mkdir -p /var/spool/lpd/foo; date; chown 4:7 /var/spool/lpd/foo; date

Actual Results:  
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.

Additional info:

I have duplicated this problem in both RH7.2 and RH7.3, on a variety of
i386-class machines.
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.
Comment 1 Bernhard Rosenkraenzer 2002-08-29 19:21:31 EDT
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.

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