I just had the most annoying Gentoo shutdown experience ever. I would therefore like to make best use of the sacrificed 17.5+ minutes shutdown time to report this bug. Situation: Notebook via WLAN connected to Home(Office) Network and mounted NFS Shares. NFS Server went down, mounts remained. Happens from time to time. Now shutdown the notebook. and You see: Waiting for netmount 50 ... 41 ... 32 ... 23 ... 14 ... 5 seconds I thought "Ok - that's understandable, because of the hanging NFS" But then after having counted that time out you read "Waiting for rpc.statd" ... 50 seconds then rpc.bind then net.lo localmount mtab root fsck modules udev udev-mount sysfs hwclock interwoven with this, there are similar timeouts of "X waiting for net.wlan0" where X is netmount mtab root fsck modules udev udev-mount sysfs hwclock After at least 1050 seconds, the system decided to reboot. Meanwhile the screensaver went on 2 times. :-) I assume openrc is responsible for this. Couldn't one establish a kind of global timeout mechanism to avoid these mindless repetitions? Reproducible: Always Steps to Reproduce: 1. Mount some NFS Share via WLAN 2. Shutdown NFS Server but do not unmount 3. Shutdown the Notebook Actual Results: see description Expected Results: Just one timeout
$ emerge --info Portage 2.1.9.6 (default/linux/amd64/10.0/desktop/kde, gcc-4.4.4, glibc-2.12.1-r1, 2.6.35-tuxonice-r1 x86_64) ================================================================= System uname: Linux-2.6.35-tuxonice-r1-x86_64-Intel-R-_Core-TM-2_CPU_T7200_@_2.00GHz-with-gentoo-2.0.1 Timestamp of tree: Wed, 15 Sep 2010 09:30:01 +0000 distcc 3.1 x86_64-pc-linux-gnu [disabled] app-shells/bash: 4.1_p7 dev-java/java-config: 1.3.7-r1, 2.1.11 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 2.0.1 sys-apps/openrc: 0.6.3 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.13, 2.67 sys-devel/automake: 1.5, 1.7.9-r1::<unknown repository>, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r1 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.35 (sys-kernel/linux-headers)
Similar to bug 256188
(In reply to comment #2) > Similar to bug 256188 Indeed, except the notebook does shutdown here after the timeout odyssey and it is reproducible (have just tried it a second time)
(In reply to comment #3) > (In reply to comment #2) > > Similar to bug 256188 > > Indeed, except the notebook does shutdown here after the timeout odyssey and it > is reproducible (have just tried it a second time) > Problem is your using a rare case where this happens. There is no way all cases can or should be supported. They are avaliable to ease the users experience.
(In reply to comment #3) > Indeed, except the notebook does shutdown here after the timeout odyssey and it > is reproducible (have just tried it a second time) > Ok, after > 1 month, do you still want us to process this bug? And what do you propose exactly? # Do we allow any started service in the runlevel to satisfy the depedency # or do we want all of them regardless of state? For example, if net.eth0 # and net.eth1 are in the default runlevel then with rc_depend_strict="NO" # both will be started, but services that depend on 'net' will work if either # one comes up. With rc_depend_strict="YES" we would require them both to # come up. #rc_depend_strict="YES" Does, setting rc_depend_strict="NO" in /etc/rc.conf change something in your case? I resolve this bug as TEST-REQUEST. Reopen if you still want this processed.
TEST-REQUEST accepted, I'm currently fine-tuning a new notebook on linux and will be in the vicinity of the NFS Server next week where I will perform the tests with the new machine.
