[arch-general] Problem with NFS on shutdown

Ronny ron9.no at gmail.com
Tue Feb 12 20:38:43 EST 2013


On Tue, 29 Jan 2013 18:01:59 +0100, Paul Marwick <paul.marwick at gmail.com>  
wrote:

> Martín Cigorraga wrote:
>> On Sat, Jan 19, 2013 at 5:55 AM, Paul Marwick  
>> <paul.marwick at gmail.com>wrote:
>>
>>> I've got two machines in my local network that provide NFS shares. One  
>>> is
>>> an old Raidsonic NAS (running a current version of OpenWRT), the other  
>>> a
>>> dedicated server running Slackware). I normally mount the shares  
>>> manually
>>> (the machine that is giving me a problem is a laptop, so its often not
>>> connected to my own network).
>>>
>>> The problem comes when I try to shut the laptop down (or restart it).
>>> Unless I've manually unmounted the NFS shares, the machine will hang  
>>> and
>>> fail to shut down. In some instances, I've been able to use CTRL-C to  
>>> break
>>> out of the stall, but frequently, I can only turn the machine off,  
>>> which is
>>> not exactly ideal.
>>>
>>> I've been playing with the nfs exports, currently have the following:
>>>
>>> /mnt/sda2/stor 192.168.1.0/255.255.255.0(rw,**
>>> sync,no_wdelay,nohide,no_root_**squash)<http://192.168.1.0/255.255.255.0(rw,sync,no_wdelay,nohide,no_root_squash)>(this  
>>> is on the Raidsonic)
>>>
>>> and
>>>
>>> /mnt/sda2/stor 192.168.1.0/255.255.255.0(rw,**
>>> sync,no_wdelay,nohide,no_root_**squash)<http://192.168.1.0/255.255.255.0(rw,sync,no_wdelay,nohide,no_root_squash)>on  
>>> the Slackware server.
>>>
>>> The problem is specific to Arch - I've got two other distros installed  
>>> on
>>> the laptop (though Arch is my usual OS). From SalineOS or Salix, the  
>>> laptop
>>> will shut down or restart without having to manually unmount the NFS  
>>> shares
>>> prior to shutdown.
>>>
>>> I suspect I've not got something set up correctly in systemd, but I'm
>>> currently at a loss to work out what. If I manually unmount the shares
>>> before shutdown, there is no problem. I've also tried adding the  
>>> unmount to
>>> /etc/rc.local.shutdown, but that doesn't work - the system still hangs
>>> during shutdown. I'm sure that rc.local.shutdown is being executed -  
>>> if I
>>> shut down without the shares mounted, I can see messages that they are  
>>> not
>>> mounted.
>>>
>>> I'm not sure if I should be looking at the NFS export parameters on the
>>> hosts, or systemd on the laptop, though I've tried some variations on  
>>> the
>>> exports without changing the behaviour.
>>>
>>> Does anyone know what I should be looking at to solve this?
>>>
>>> Paul.
>>>
>>>
>> Same issue here with NFS4 (both laptop and NAS are Arch), if I find  
>> what's
>> happenings I post back.
> I've had a suggestion that the problem may be due to NetworkManger - if  
> the network goes down before the NFS shares are unmounted, the sort of  
> hang that I'm seeing will happen.
>
> I am using NetworkManager, so it does seem to be a possibility. I'm not  
> sure how to check at what point in the shutdown cycle the network is  
> disabled. I have a couple of ways of testing it (one possibility may be  
> to try a wired network, which should connect and disconnect  
> independently of NetworkManager), so I'll post back if I can prove or  
> disprove the theory.
>
> The other option is to replace NetworkManager with wicd (which, so far  
> as I can remember does not disconnect the network when the desktop is  
> shut down).
>
> I will do some testing and post back the results. It would be  
> interesting if anyone knows how the shut down sequence works, especially  
> when the network is disconnected.
>
> Paul.

If you look in the <journalctl -b | grep -i systemd> log I think you will  
see that the NSF will be mounted early in the boot process and  
network.target gets started late in the boot because renaming occurs so  
late. When the system goes down the process is reversed and network.target  
stops early in the shutdown and the network is down long before nfs is  
unmounted.
I think Sudaraka's solution may work.
-- 
ron9


More information about the arch-general mailing list