The following reply was made to PR bin/36506; it has been noted by GNATS.

From: Hauke Fath <hauke@Espresso.Rhein-Neckar.DE>
To: gnats-bugs@NetBSD.org
Cc: gnats-admin@NetBSD.org, Matthias Scheler <tron@zhadum.org.uk>
Subject: Re: bin/36506: /etc/rc.d/amd prohibits reboot if amd owns /home
Date: Mon, 18 Jun 2007 21:27:41 +0200

 At 12:05 Uhr +0000 18.6.2007, Matthias Scheler wrote:
 > On Sun, Jun 17, 2007 at 07:00:01PM +0000, Hauke Fath wrote:
 > >  What sounds like a good idea ends up blocking a reboot if
 > > (1) amd manages nfs mounts under /home, and
 > > (2) a shutdown -r is issued by a non-root member of group operator
 > > with a home directory managed by amd..
 >
 > Why should that block the reboot?
 
 Good question. It shouldn't. All I know is that it does.
 
 >All the process should use
 > "/amd/server/what/ever/serverfilesystem" and not "/home" anyway.
 
 [netbsd-4 snapshot of 2007-06-18]
 
 [hauke@fattie] ~ > df
 Filesystem  1K-blocks      Used     Avail Capacity  Mounted on
 /dev/sd0a      872303    342534    486154    41%    /
 /dev/sd0g     3877982    389886   3294198    10%    /var
 tmpfs          405784       104    405680     0%    /var/run
 /dev/sd0e     5623924   1914104   3428624    35%    /bsdsrc
 /dev/sd0f    21327036    655332  19605354     3%    /local
 kernfs              1         1         0   100%    /kern
 tmpfs          405684         4    405680     0%    /tmp
 pizza:/home   7767678   1075830   6303466    14%    /amd/pizza/home
 [hauke@fattie] ~ > cd /
 [hauke@fattie] / > fstat -f /home
 USER     CMD          PID   FD MOUNT       INUM MODE         SZ|DV R/W
 [hauke@fattie] / > fstat -f /amd/pizza/home/
 USER     CMD          PID   FD MOUNT       INUM MODE         SZ|DV R/W
 hauke    xterm        543   wd /amd/pizza/home  207360 drwxr-xr-x    4608 r
 hauke    tcsh         542   wd /amd/pizza/home  207360 drwxr-xr-x    4608 r
 root     rshd         523   wd /amd/pizza/home  207360 drwxr-xr-x    4608 r
 [hauke@fattie] / > shutdown -r now
 Shutdown NOW!
 shutdown: [pid 698]
 
 *** FINAL System shutdown message from hauke@fattie ***
 System going down IMMEDIATELY
 
 
 [hauke@fattie] / >
 System shutdown time has arrived
 
 About to run shutdown hooks...
 Stopping cron.
 Waiting for PIDS: 490.
 Stopping inetd.
 Waiting for PIDS: 477.
 Stopping amd.
 Waiting for PIDS: 306, 306, 306, 306, 306, 306, 306, 306, 306, 306, 306,
 306, 306, 306, 306, 306, 306, 306, 306, 306, 306, 306, 306, 306, 306, 306,
 306, 306, 306, 306, 306, 306, 306, 306, 306, 306 [ad nauseam]
 
 -- from here, the only way out is to become root and issue a reboot(8). Too
 bad, if you're member of operator, but not wheel.
 
 > Backing out that change is not an option. I've added it because
 > I frequently had problems with unmounting filesystem on my server
 > during a shutdown or reboot.
 >
 > This happened because the amd(8) process got terminated but the
 > pseudo NFS mounts were still active. The kernel tried to unmount
 > them but didn't succeed because the NFS request didn't get handled.
 
 We're relying heavily on amd(8) at work for mounting user homes as well as
 general purpose fileserver storage on NetBSD 1.6 - 3, and RedHat / Debian
 Linuxes. I even handeled removable media with it, although it's a pain. I
 haven't seen any issues with shutting down amd in three years - unless the
 machine was hosed anyway, that is.  I don't debate the scenario you mention
 is possible, but I haven't seen it.
 
 OTOH, the above issue is easily reproducible: Calling /etc/rc.d/amd stop
 while processes still have files open in amd-managed trees is going to loop
 forever. So, if you insist on explicitely stopping amd during shutdown, you
 need to ensure that all user processes that could possibly have files open
 in amd-managed trees are gone by that time.
 
 	hauke
 
 
 
 
 
 --
 "It's never straight up and down"     (DEVO)