Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 42139 - using udev + NIS prevents clean shutdown
Summary: using udev + NIS prevents clean shutdown
Status: RESOLVED WORKSFORME
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] baselayout (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: Gentoo's Team for Core System packages
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-19 05:24 UTC by Ernst Bachmann
Modified: 2005-09-13 07:14 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ernst Bachmann 2004-02-19 05:24:03 UTC
my gentoo box is in a NIS domain, I'm using a 2.6 kernel and udev.
Now when I shutdown, /etc/init.d/halt.sh tries to execute pam_console_apply -r and then tar to save the exisiting device nodes to /lib/udev-state/devices.tar.bz2. The problem is, that the loopback network device is already down at that state, so that both pam_console_apply and tar hang while trying to contact/verify the existence of ypbind/nscd.
When I bring lo back up by hand, the script finishes.


Reproducible: Always
Steps to Reproduce:
1. use udev + NIS
2. try to shutdown.


Actual Results:  
the system didn't perform a clean shutdown. 

Expected Results:  
save the device nodes, and power down. 

Suggestions on how to fix it: 
Either don't have net.lo disable the loopback device, or don't save the device 
nodes at all on shutdown, provide a script for doing so manually.
Comment 1 Martin Schlemmer (RETIRED) gentoo-dev 2004-02-26 13:26:46 UTC
I am open to suggestions, as I do not have NIS to test this.
Comment 2 Ernst Bachmann 2004-02-27 06:55:41 UTC
Ok, some suggestions:

1) remove the stop() part from /etc/init.d/net.lo
Thats what I did, solved the problem for me, and I don't see
much sense in stopping the loopback device anyways.

2) issue "/sbin/ifconfig lo up" in halt.sh before the pam_console_apply and tar commands.
Might solve the problem, but doesn't seem like a good way to do it.

3) have /etc/inid.d/ypbind remove all NIS references in /etc/nsswitch.conf on stop, reestablish them on startup again. (Seems quite error-prone to me, in case of power-loss or reboots without going to the stop scripts)

4) wait till udev supports all devices, then there won't be a need for /lib/udev-state/devices.tar.bz2 any more, remove that part completely.
This would IMHO be the best solution, but can't be done till all char devices are handled by udev.

I didn't test it, but I think you don't need an actial NIS domain to verify that behavior:

just changing "passwd: compat" to "passwd: db files nis" could cause the same problem.
Comment 3 Spooky Ghost 2004-03-15 06:30:57 UTC
I experienced this problem too with NIS and NFS/autofs homes.  If an NIS user is logged in with NFS home directory mounted the shutdown is unclean.  If all users apart from root are logged out the shutdown runs correctly.
Comment 4 Brett Johnson 2004-10-30 07:32:08 UTC
I have this same problem, but I don't use NIS, I only use NFS. I have home and a few other file systems mounted as NFS, and if I shutdown with a normal user logged in, it hangs on the tar command (Saving Device Nodes). If all normal users are logged off, the shutdown executes as expected.

I have tried setting the RC_DEVICE_TARBALL to no in /etc/conf.d/rc, and the shutdown does complete with a user logged in, however, the system does not boot becuase the LVM devices are missing on startup.

I have tired commenting out the "ifconfig down" command in net.lo stop function, that did not seem to help the issue.

I have also tried writting a script executable by a normal user, that calls /sbin/halt, sleeps for 3 seconds, and then kills the parent process ($PPID), which should log the user off, but that doesn't work either.
Comment 5 Matt Drew (RETIRED) gentoo-dev 2005-01-10 05:12:45 UTC
bug #31877 appears to cover part of this problem.
Comment 6 Ernst Bachmann 2005-09-13 07:14:45 UTC
in the progress of working on bug #31877, this problem has been fixed as a side  
effect (pam_console_apply isn't called any more)  
  
The real problem behind it (loopback network device down while it might still  
be needed by halt.sh) hasn't been fixed afaik, but with the new baselayout its  
not a problem any more (as long as you don't use pam_console, but who'd want  
that) 
 
Many Thanks to everyone involved.