shutdown hangs *stopping enhanced syslogd: rsyslogd*

[go4linux]

After further investigation I think the problem is that the network is taken down (network-manager/wicd killed) before nfs is unmounted causing the umount command to hang.
As a temporary fix I have disabled network-manager and configured my wireless with the interfaces file.

I have the same problem, and I agree on the cause. So I looked at /etc/rc0.d, and I don't understand a couple of things:

- why is network-manager called before umountnfs.sh?
- why is sendsigs not called at last? and why is rpcbind one of the processes excluded from the list of processes to kill?

[Christopher888]

Hi,

I am experiencing this problem on wheezy and cannot shutdown my system.

I can confirm that this is related to nfs. Any word on a fix?

[jpaulb]

I did an update and the problem went away.

[nilssn]

Still having this problem with an updated Testing.

[jpaulb]

I have done a couple updates and the problem has gone away for the time being

[layr]

Still no solution for this issue?
EDIT: my workaround:
being root, create file unmount_nfs.sh in /etc/init.d/ with the following contents and make it executable.

Code: Select all

#!/bin/bash
#script for automatic unmounting of nfs drive on reboot and shutdown
umount /mnt/server
exit

( /mnt/server should be replaced by your mount point)

Then in terminal, also being root, run

Code: Select all

update-rc.d unmount_nfs.sh start 20 0 6 .

(including the period)

[cuda]

I also have this issue with a NFS drive and wireless/network-manager connection on my laptop.

I've been having good luck with this network-manager script which I put in the /etc/NetworkManager/dispatcher.d directory. I called it 00nfs and made it executable. It simply mounts or unmounts all the NFS shares whenever the connection goes up or down. I still kept all of my NFS mount information in /etc/fstab.

/etc/NetworkManager/dispatcher.d/00nfs

Code: Select all

#!/bin/sh

# mount/unmount NFS shares on network-manager up/down events.

case "$2" in
	up)
		mount -a -t nfs4
		;;
	down)
		umount -a -t nfs4
		;;
esac

Note that the -t option seems to be finicky about whether you specify nfs or nfs4. If I specify nfs as the filesystem type in fstab, I am able to mount all of my NFS4 shares with -t nfs, but to unmount them I have to use -t nvf4. For consistency, I specify nfs4 everywhere.

[parmenion]

I've had a similar problems having a some cifs filesystems mounted.
I've solved the problem by renaming the kill-scripts to change the order of execution:

Code: Select all

mv /etc/rc0.d/K04rsyslog /etc/rc0.d/K05rsyslog
mv /etc/rc0.d/K05umountnfs.sh /etc/rc0.d/K04umountnfs.sh
mv /etc/rc6.d/K04rsyslog /etc/rc6.d/K05rsyslog
mv /etc/rc6.d/K05umountnfs.sh /etc/rc6.d/K04umountnfs.sh

But i'm not sure if this the right way to fix the problem.

[llivv]

Have any of the first three posters int his thread tried installing the testing default kernel to see if it works?

[parmenion]

I've to begdown: the renaming did not fix it. I don't know why but the effekt reoccured.

I've investigated a bit further:
My network connection is via WLAN and read about problems with unmounting file systems when the network-manager has already stop.

[parmenion]

Some more information. The effect das not occure if do no X-Login. If i do just das console login as root I can shutdown normally. I do a X-Login the shutdown hangs at rsyslog.

[llivv]

I've had a similar problems having a some cifs filesystems mounted.
I've solved the problem by renaming the kill-scripts to change the order of execution:

Code: Select all

mv /etc/rc0.d/K04rsyslog /etc/rc0.d/K05rsyslog
mv /etc/rc0.d/K05umountnfs.sh /etc/rc0.d/K04umountnfs.sh
mv /etc/rc6.d/K04rsyslog /etc/rc6.d/K05rsyslog
mv /etc/rc6.d/K05umountnfs.sh /etc/rc6.d/K04umountnfs.sh

But i'm not sure if this the right way to fix the problem.

sorry to interrupt here, in the interest of reducing some of the confusion of this thread,
are you sure it's the same problem?

did you run update-rc.d after reordering the kill links?
if yes, were there error messages?

which debian release are you using?
which kernel are you using?

[parmenion]

which debian release are you using?
which kernel are you using?

I'm using wheezy:

Code: Select all

#uname -a
Linux xxxxxxxxxx 3.2.0-4-686-pae #1 SMP Debian 3.2.39-2 i686 GNU/Linux

did you run update-rc.d after reordering the kill links?
if yes, were there error messages?

No. I did not use update-rc.d.

[stevetf]

I've had a similar problems having a some cifs filesystems mounted.
I've solved the problem by renaming the kill-scripts to change the order of execution:

Code: Select all

mv /etc/rc0.d/K04rsyslog /etc/rc0.d/K05rsyslog
mv /etc/rc0.d/K05umountnfs.sh /etc/rc0.d/K04umountnfs.sh
mv /etc/rc6.d/K04rsyslog /etc/rc6.d/K05rsyslog
mv /etc/rc6.d/K05umountnfs.sh /etc/rc6.d/K04umountnfs.sh

But i'm not sure if this the right way to fix the problem.

More of a "workaround" than a "fix" I think, but a similar workaround worked for me too.
I'm also on Wheezy (just updated from Squeeze).

My amateur analysis of what is occurring:
What has been done in the above is to stop rsyslog before unmounting the network drive. This means that rsyslog does not see that the network drive has not been unmounted (because rsyslog halts before the problem arises).
What I did was to ensure that the network drive was unmounted earlier.

(I'll give a detailed description as this may help others that have the same problem. Anything in chevrons "<>" needs to be replaced with whatever is appropriate for your computer.)

umountnfs.sh was not unmounting the network drive fast enough. Even though the network shutdown is lower priority than unmounting the drive, the network shutdown completed before the drive was unmounted so umountnfs.sh was unable to complete, which was then detected by rsyslog, which would then wait forever for the drive to be unmounted (which never happens).

How I worked around the problem was to force the unmount earlier.

I wrote a short script and named it "umount_<device-name>/sh"

Code: Select all

#!/bin/bash
#script for automatic unmounting of nfs drive on reboot and shutdown
umount /<mount-point>/<device-name>
exit

That script goes into /etc/init.d

Code: Select all

sudo mv <dir>/<"umount_device-name>  /etc/init.d

The command umount /<mount-point>/<device-name> needs to be the appropriate command to unmount the network drive. You can test the command from a Terminal by running it as root (sudo on Debian/Ubuntu) and check that it actually does unmount the device.

A syslink then needs to be made in /etc/rc0.d
The name of the link needs a "K" number adding onto the start. The "K" number sets the priority and needs to definitely be before the network is shut down. I set it to be the first thing to shut down by calling it "K20umount_<device-name>" ("20" is a higher number than any of the existing link names).

Code: Select all

sudo ln -s /etc/init.d/umount_<device-name>.sh /etc/rc0.d/K20umount_<device-name>.sh

Reboot.

That should be all.

[ndandanov]

I've had a similar problems having a some cifs filesystems mounted.
I've solved the problem by renaming the kill-scripts to change the order of execution:
........
A syslink then needs to be made in /etc/rc0.d
The name of the link needs a "K" number adding onto the start. The "K" number sets the priority and needs to definitely be before the network is shut down. I set it to be the first thing to shut down by calling it "K20umount_<device-name>" ("20" is a higher number than any of the existing link names).

Dear stevetf,

Thank You very much for the insight!

The same problem occured in my situation, where I'm using two Samba shares.

However, Your solution didn't quite work for me at the beginning.
I had to create a symlink to a lower number than the one of rsyslog (K04). That's why I renamed it to K03, but then installed Virtualbox which renamed it to K01umount_smb.sh.
I then created the same symlink in /etc/rc6.d/ (https://wiki.debian.org/RunLevel) in order to have the same effect when rebooting.

Now all seems to be running fine. The shares should be getting unmounted before rsyslog is stopped.

Thank You again and sorry for any misleading information I've posted. I'm not very experienced with Linux and Debian.


Best regards,
Nickolay

[erlguta]

Hi,

I am suffering this issue on debian jessie with systemd version 204-8 configured and network-manager 0.9.8.10-3

The system completely hangs on shutdown when a NFS share is mounted.

I have tested it several times, and even with the _netdev fstab option it hangs all the times, and when I umount that nfs share it shutdown like a charm... so the evidence is clear.

My question is:

I have created one new LSB script, that is the first to execute on 0 and 6 runlevels (shutdown), and what it do is just to umounts NFS shares.
And it is hanging on shutdown with systemd configured...
so, is systemd ignoring the order sequence on shutdown and executing it on parallel?
How to solve this with systemd and let it shutdown gracefully?
How NFS is very common, I suppose that many of you a suffering this issue.
How are you solving it?

Thanks in advance,

Gonzo

[Talkless]

I have similar problem with Sysvinit and CIFS mount, reported bug here:

https://bugs.debian.org/cgi-bin/bugrepo ... bug=772914