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."
NFS is stateless from the server's perspective. This is done so that the server doesn't have to track the state of a whole fleet of clients (and so that the server can pick up where it left off when it crashes and restarts).
So the server, by design, has no notion of the number / names of users connected to it.
The best you could do would probably be to monitor NFS traffic, and present a dialog on shutdown if there has been any traffic in the last 5 minutes or so.
but wouldn't one key things to consider when building such a system be that a) it's down as little as possible and b) when it goes down it's well known beforehand(and the users can be told in advance that it will go down at time x and they're fsced if they don't get out before it).
look, what point would there be in initiating the shutdown if you didn't know when the users will get out anyways? it could take hours/days before it would actually boot, and if that doesn't matter(waiting _hours_) then why would you be booting it in the first place? just out of habit?
anyways.. it sounds a lot like you should be fixing on why you have to be booting it instead of how the booting occurs.. so that you wouldn't need to be booting it.
world was created 5 seconds before this post as it is.
Even better thought, he could decide that there actually is a distinction between server duty and workstation duty and decide which this particular machine is going to pull. If he needs the machine to run as a workstation, quit trying to use an unstable environment as a server. If the files and stability of the system are of any importance whatsoever then it is a server, treat it as such and buy another computer to use as a workstation (they are dirt cheap now.) Pretty simple.
.5 to 1GHz range with a CRT.)
Want to see your uptime and stability rise incredibly on the server? Put it in the closet on a UPS and once it is running turn off the monitor, unplug the keyboard, and tape a piece of cardboard over the power switch so it doesn't get turned off by accident. Where the machine used to sit put a cheap replacement computer to use as a workstation - even new entry level boxes are starting at under $500 fully loaded (a little wimpy, but including all the necessary parts including a monitor) and used hardware has gotten insanely cheap (ie $200 for a full machine that is a generation or two old, PIII
That said, I am going to read every post in this thread to get a better understanding of how to do this - now you have my interest up.
Glonoinha the MebiByte Slayer
At larger sites, you also get some other great benefits, like being able to move filesystems transparently from one server to another without touching the clients, all by managing the automounter map.
Most Unix and Linux variants have a standard automounter. Use it! This will lead to two possible scenarios when the fileserver goes down:
Idle filesystems which have been unmounted.
Active filesystems which remain mounted.
rather than . You may want to add behavior to the shutdown script which sends an announcement to the clients using , sends a remote command to the clients to shut down any specialized applications which are known to depend on shared files, puts up a confirmation prompt on the server, or the like.You have to be clear about why filesystems are active in the second case. For example, clients which are running daemons or other always-on software should not be using NFS files, otherwise you've engineered yourself a brittle metasystem. Daemons should run out of the local filesystems only.
User applications which write frequently to the home directory are another common source of filesystem dependency. The idea of a central home directory is architecturally excellent. Just don't abuse it. If an application really needs the NFS home directory, then it can wait until the server is back up. Otherwise, fix the application.
Of course you already bring the server down gracefully, using