Slashdot Mirror

← Back to Stories (view on slashdot.org)

Preventing Shutdown on Active NFS Servers?

Posted by Cliff on from the disconnect-your-shares,-first dept.

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."

4 of 66 comments (clear)

  1. use correct mount options by stevef · · Score: 5, Interesting

    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

  2. maybe... by Froze · · Score: 3, Interesting

    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.
  3. NFS Locking Service might work? by stefanlasiewski · · Score: 4, Interesting

    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."
  4. Re:Mod parent up by HalfFlat · · Score: 3, Interesting

    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.