Slashdot Mirror
Preventing Shutdown on Active NFS Servers?
Ed Almos asks: "Like many Slashdot Readers, I run a small network at home with a server and a number of desktops. The server holds all our files as NFS shares and doubles as a desktop machine should the need arise. Problems however occur if the server is shut down whilst there are NFS shares in use, the minimum disruption is a crashed desktop and a couple of times I have had to deal with corrupted files. Does anyone know of a way to prevent shutdown of a machine if someone else has drives mounted to its NFS shares ? I have already explored use of the /etc/shutdown.allow file but all this does is determine who can kill the machine. The minimal solution would be something similar to a Microsoft Windows system, where a request to shutdown brings up a warning window that there are users connected to the system, but I am not sure how to achieve this on a Linux system. Ideally I would like to prevent shutdown of a system with active NFS shares altogether, or at least until the user has unmounted and logged off the network."
1) Put a big piece of tape/wood/whatever protecting the power switch on the NFS server, and disable software shutdown by non-root.
2) Put your NFS server on the *best* machine, not the worst one, so that users want to use it first. If worst comes to worst, put signs on the other machines advertising the other's superiority. (and without the NFS overhead, it will really outperform its clients!)
3) Put your NFS server on a g3 laptop or other ultra low power system, and hide the system in your closet so others can't find it to turn it off. (hardware suggestions, anyone?)
4) switch to samba (heh heh heh)
If I understand you correctly, it sounds like you just want to replace shutdown with a wrapper script.
/sbin/shutdown to something like /sbin/shutdown.real.
/sbin/shutdown that checks for your NFS mounts before invoking shutdown.real.
/etc/fstab...or just compare /etc/mtab to /etc/fstab. Whatever....just look to see that your have NFS mounts. If you do, don't shutdown; if you don't, go ahead and shutdown.
a) Move
b) Write a shell script called
If you want to make it really fancy, you can do something like calling and parsing the output of 'df', comparing that to the contents of
Is that what you want? If that *is* what you want, make sure you backup your wrapper and be aware that the next time you upgrade your base system, the wrapper will get blown away. Also make sure your wrapper script is passing all command options to the real shutdown.
Tyler's words coming out of my mouth.
If you use the correct mount options you should not have to worry about corruption when the nfs server goes away.
The options you want (for filesystems mounted rw) are:
rw,hard,nointr...
A lot of people don't like these options because it means that the clients will hang until the server returns, but it is THE RIGHT THING TO DO if you are mounting important data rw. If you can't stand for your clients to hang, maybe replace 'nointr' with 'intr', but you've been warned.
Steve
use lsof to monitor tcp/udp/rcp sockets that are open on the host and pointing at the file space that nfs is serving.
/.?
Then write a wrapper around each of halt, shutdown, and reboot to check the open ports and fail if they are active.
Seems fairly hackish, but... whaddya expect from
-- The morphemes of your disquisition are ascertainable, but they have eschewed an ambit of transpicuous exposition.
I can't remember the details on this, but would the NCF Locking Services work for you?
NFS input/output is stateless, but I believe the locking mechanism is stateful.
When clients are accessing a file, a lock is established. When the client is done with the file, the lock is removed. You can see who has what resource locked with a utility (I forget which, but fcntl() and lockf() come to mind).
In a shutdown script, look for locks, and refuse to procede until the locks are cleared.
"Can of worms? The can is open... the worms are everywhere."
Back when I was administering a mixed Unix network, we used to say the two NFS mount options were 'hard' and 'corrupt'.
I believe that it is theoretically possible to write software that can survive a soft mounted filesystem disappearing from under it, but no one ever does. How often do people check the return value from write()? And in memory mapped io land, it would be nasty.
As a hack, you could replace /sbin/shutdown with a shell script that pops up a dialog (If $DISPLAY is set) or asks on the console.
tasks(723) drafts(105) languages(484) examples(29106)
I know that it's not quite what you wanted, but using Coda, which is designed to support disconnected operation (i.e. servers goes away for a while and then comes back) may be an appealing option for you.
May we never see th
Where I work they had this problem and someone implemented a automounter program that mounts the shares when they are needed and releases them as soon as they are not needed. Not a perfect solution but it works really well.
The file /var/lib/nfs/rmtab on the server keeps a list of what systems have mounted NFS drives. What you then do is this:
1. When shutting down, first go through rmtab and send an rwall message to those machines, saying 'get the heck off because the server is going down shortly'
2. Two minutes later try again and send a more forceful message.
3. Two minutes later tell them they are about to get it in the neck. And shutdown.
If you really dont want to shut the machine down with NFS mounted stuff still there, then modify to taste - dont shutdown unless rmtab doesn't have any shares from machines you dont want to annoy.
This is untested of course.... Until you try it! Read the warnings about rmtab in man mountd. It may not be trustworthy.
Baz