On suspend NetworkManager deconfigures the network, killing NFS mount and hanging GNOME, etc.

Bug #516592 reported by Chris
56
This bug affects 11 people
Affects Status Importance Assigned to Milestone
NetworkManager
Expired
High
network-manager (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

Binary package hint: network-manager

When the system is going to sleep Network Manager unloads the network interface even though the home directory is NFS loaded on that interface.
Obviously there is still more work happening on that directory and so the system hangs on I/O in the case where NFS is mounted with the hard option.
This prevents power saving and the system is unusable as Network Manager dies with the rest of Gnome all waiting for I/O
If you log in on one of the TTYs shutting the system down cleanly fails on the kernel hung I/O and so the only way out is to press the reset button.

here is the syslog output showing network manager stopping the nic just before the kernel says ouch I have no file system to talk to:
Feb 2 21:33:53 desktop kernel: [19339.921076] CPU0 attaching NULL sched-domain.
Feb 2 21:33:53 desktop kernel: [19339.921090] CPU1 attaching NULL sched-domain.
Feb 2 21:33:53 desktop kernel: [19339.961405] CPU0 attaching sched-domain:
Feb 2 21:33:53 desktop kernel: [19339.961414] domain 0: span 0-1 level SIBLING
Feb 2 21:33:53 desktop kernel: [19339.961421] groups: 0 1
Feb 2 21:33:53 desktop kernel: [19339.961434] CPU1 attaching sched-domain:
Feb 2 21:33:53 desktop kernel: [19339.961439] domain 0: span 0-1 level SIBLING
Feb 2 21:33:53 desktop kernel: [19339.961445] groups: 1 0
Feb 2 21:33:53 desktop anacron[2176]: Normal exit (0 jobs run)
Feb 2 21:33:54 desktop NetworkManager: <info> Sleeping...
Feb 2 21:33:54 desktop NetworkManager: <info> (eth0): now unmanaged
Feb 2 21:33:54 desktop NetworkManager: <info> (eth0): device state change: 8 -> 1 (reason 37)
Feb 2 21:33:54 desktop NetworkManager: <info> (eth0): deactivating device (reason: 37).
Feb 2 21:33:54 desktop NetworkManager: <info> (eth0): canceled DHCP transaction, dhcp client pid 839
Feb 2 21:33:54 desktop NetworkManager: <WARN> check_one_route(): (eth0) error -34 returned from rtnl_route_del(): Sucess#012
Feb 2 21:33:54 desktop NetworkManager: <info> (eth0): cleaning up...
Feb 2 21:33:54 desktop NetworkManager: <info> (eth0): taking down device.
Feb 2 21:33:54 desktop NetworkManager: <info> (wlan0): now unmanaged
Feb 2 21:33:54 desktop NetworkManager: <info> (wlan0): device state change: 3 -> 1 (reason 37)
Feb 2 21:33:54 desktop NetworkManager: <info> (wlan0): cleaning up...
Feb 2 21:33:54 desktop NetworkManager: <info> (wlan0): taking down device.
Feb 2 21:33:55 desktop NetworkManager: <info> (eth0): carrier now OFF (device state 1)
Feb 2 21:36:55 desktop kernel: [19521.570035] nfs: server nfs.office.local not responding, still trying
Feb 2 21:36:56 desktop kernel: [19522.710031] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:03 desktop kernel: [19529.660034] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:17 desktop kernel: [19543.690033] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:26 desktop kernel: [19552.670037] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:27 desktop kernel: [19553.670029] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:29 desktop kernel: [19555.660034] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:33 desktop kernel: [19559.470051] nfs: server nfs.office.local not responding, still trying
Feb 2 21:37:34 desktop kernel: [19560.950099] INFO: task sync:2239 blocked for more than 120 seconds.
Feb 2 21:37:34 desktop kernel: [19560.950184] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
Feb 2 21:37:34 desktop kernel: [19560.950267] sync D 00000000ffffffff 0 2239 2104 0x00000000
Feb 2 21:37:34 desktop kernel: [19560.950279] ffff8800228d1c58 0000000000000086 ffff880001a23880 0000000000015880
Feb 2 21:37:34 desktop kernel: [19560.950290] ffff880010115e70 0000000000015880 0000000000015880 0000000000015880
Feb 2 21:37:34 desktop kernel: [19560.950299] 0000000000015880 ffff880010115e70 0000000000015880 0000000000015880
Feb 2 21:37:34 desktop kernel: [19560.950309] Call Trace:
Feb 2 21:37:34 desktop kernel: [19560.950328] [<ffffffff810da7f0>] ? sync_page+0x0/0x50
Feb 2 21:37:34 desktop kernel: [19560.950338] [<ffffffff81527c98>] io_schedule+0x28/0x40
Feb 2 21:37:34 desktop kernel: [19560.950346] [<ffffffff810da82d>] sync_page+0x3d/0x50
Feb 2 21:37:34 desktop kernel: [19560.950354] [<ffffffff815283c7>] __wait_on_bit+0x57/0x80
Feb 2 21:37:34 desktop kernel: [19560.950363] [<ffffffff810da99e>] wait_on_page_bit+0x6e/0x80
Feb 2 21:37:34 desktop kernel: [19560.950373] [<ffffffff81078b60>] ? wake_bit_function+0x0/0x40
Feb 2 21:37:34 desktop kernel: [19560.950383] [<ffffffff810e4d20>] ? pagevec_lookup_tag+0x20/0x30
Feb 2 21:37:34 desktop kernel: [19560.950391] [<ffffffff810dae45>] wait_on_page_writeback_range+0xf5/0x190
Feb 2 21:37:34 desktop kernel: [19560.950401] [<ffffffff810e4d20>] ? pagevec_lookup_tag+0x20/0x30
Feb 2 21:37:34 desktop kernel: [19560.950411] [<ffffffff81012bae>] ? apic_timer_interrupt+0xe/0x20
Feb 2 21:37:34 desktop kernel: [19560.950421] [<ffffffff811357a6>] ? generic_forget_inode+0x1b6/0x240
Feb 2 21:37:34 desktop kernel: [19560.950429] [<ffffffff810daf07>] filemap_fdatawait+0x27/0x30
Feb 2 21:37:34 desktop kernel: [19560.950439] [<ffffffff8113fb56>] generic_sync_sb_inodes+0x366/0x530
Feb 2 21:37:34 desktop kernel: [19560.950449] [<ffffffff8116f896>] ? vfs_quota_sync+0x186/0x200
Feb 2 21:37:34 desktop kernel: [19560.950457] [<ffffffff810e39f8>] ? do_writepages+0x28/0x50
Feb 2 21:37:34 desktop kernel: [19560.950466] [<ffffffff8113fdbe>] sync_inodes_sb+0x9e/0xb0
Feb 2 21:37:34 desktop kernel: [19560.950475] [<ffffffff81143b90>] __sync_filesystem+0x30/0x70
Feb 2 21:37:34 desktop kernel: [19560.950483] [<ffffffff81143c97>] sync_filesystems+0xc7/0x120
Feb 2 21:37:34 desktop kernel: [19560.950492] [<ffffffff81143d4c>] sys_sync+0x1c/0x40
Feb 2 21:37:34 desktop kernel: [19560.950500] [<ffffffff81012002>] system_call_fastpath+0x16/0x1b

ProblemType: Bug
Architecture: amd64
CRDA: Error: [Errno 2] No such file or directory
Date: Wed Feb 3 15:23:26 2010
DistroRelease: Ubuntu 9.10
Gconf:

IfupdownConfig:
 auto lo
 iface lo inet loopback
IpRoute:
 10.10.10.0/24 dev eth0 proto kernel scope link src 10.10.10.124 metric 1
 169.254.0.0/16 dev eth0 scope link metric 1000
 default via 10.10.10.2 dev eth0 proto static
NonfreeKernelModules: nvidia
Package: network-manager 0.8~a~git.20091013t193206.679d548-0ubuntu1
ProcEnviron:
 LANG=en_GB.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-17.54-generic
SourcePackage: network-manager
Uname: Linux 2.6.31-17-generic x86_64
WpaSupplicantLog:

Revision history for this message
Chris (cslee-launchpad) wrote :
Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Oliver Joos (oliver-joos) wrote :

As I wrote on similar bug 792007 I am always able to release the blocking by restarting network-manager. Try:
  sudo service network-manager restart

Please leave a comment here if you know a permanent workaround to automatically unmount nfs shares BEFORE the network-manager disconnects.. It seems that scripts in /usr/lib/pm-utils/sleep.d/ get executed too late.

Revision history for this message
Casandro (casandro-lion) wrote :

Unmounting the NFS home directory won't work, perhaps that's even where it hangs.

The Problem still exists on 12.04

Would there be a way to disable network manager while still getting your interfaces configured?

Revision history for this message
Casandro (casandro-lion) wrote :

Disabling network manager seems to fix the problem.
in
/etc/NetworkManager/NetworkManager.conf
Add
[ifupdown]
ifupdown:managed=true

Then also configure your network in /etc/network/interfaces, and don't forget the dns-nameservers entry.

It seems like the bug is NetworkManager disabling the interface before going into standby. I have no idea to why this is done, but it certainly breaks nfs home directories.

Revision history for this message
Oliver Joos (oliver-joos) wrote :

@Casandro: your fix sounds promising! So I tried it on my Natty, but it did not help.

Symptoms I see: if any nfs share (not just /home) is still mounted when going to sleep the system seems to resume immediately but with network-manager stopped, and (as consequence) any further access to the nfs share will block the accessing process (e.g. nautilus). Restarting network-manager will unblock those processes and (surprisingly) continue the previously interrupted sleep!
I still did not find a work-around.

Revision history for this message
Casandro (casandro-lion) wrote :

@Oliver Joos
You need up disable NetworkManager so it won't interfere with the kernel.
The kernel itself will bring up your network interface exactly as it has been before entering suspend.

Revision history for this message
Oliver Joos (oliver-joos) wrote :

Oh I see. But disabling network-manager as a whole is not an option for me. I need its WLAN roaming and VPN capabilities.

Thanks for confirming, that this bug seems to be in network-manager. I agree with that and reported it upstream: https://bugzilla.gnome.org/show_bug.cgi?id=677053

Changed in network-manager:
importance: Unknown → High
status: Unknown → New
Revision history for this message
Jörg Steffens (joerg-steffens) wrote :

I've experienced the same problem with openSUSE 12.1 and KDE or xfce. I've found a clumsy workaround, that might also help here:

When the system should be suspended, the NetworkManager gets notified by a dbus call. You can generate this call manually by

qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.Sleep boolean:true

This results, that NetworkManager shuts down all its network interfaces.

To wake him up again, following call can be used:

qdbus --system org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager.Sleep boolean:false

At SUSE, this call is performed by /usr/lib/pm-utils/sleep.d/55NetworkManager
and can be overwritten by /etc/pm/sleep.d/55NetworkManager

Disabling this call, results into a working suspend mechanism for KDE and a NFS Home directory.
However, xfce additional calls org.freedesktop.NetworkManager.Sleep boolean:true directly.
However, modifying this file to always wake-up NetworkManager results into a working (but clumsy solution), because,

xfce calls NetworkManager sleep
NetworkManager shuts down all network interfaces
[...]
modified /etc/pm/sleep.d/55NetworkManager wakes up NetworkManager again
Network connections are reestablished again
[...]
system is going into suspend.

I don't have a Ubuntu at hand, but I expect, that this workaround can be adapted for Ubuntu and Gnome.

Thomas Hood (jdthood)
tags: added: precise
summary: - Network manager kills NFS link on going to sleep hanging Gnome etc.
+ On suspend NetworkManager deconfigures the network, killing NFS mount
+ and hanging GNOME, etc.
Revision history for this message
Mathieu Trudel-Lapierre (cyphermox) wrote :

No, this should have been fixed in the 12.04 release. If it's not, please file your own bug report (unless you're Chris), and make sure to add all the relevant information, including the file /var/log/syslog and the contents of /etc/network/interfaces.

Chris, if you're still seeing this, please use 'apport-collect 516592' to add debugging data to this bug report.

Changed in network-manager (Ubuntu):
status: Confirmed → Incomplete
importance: Undecided → Medium
Revision history for this message
Thomas Hood (jdthood) wrote :

@Chris: Can you reproduce the bug in Ubuntu 12.04?

Changed in network-manager:
status: New → Expired
Revision history for this message
Thomas Hood (jdthood) wrote :

Pavel Simerda upstream says to use dispatcher.d/.

Revision history for this message
Chris (cslee-launchpad) wrote :

Unfortunately I have not upgraded yet, but as my NFS machines are all wired machines just removing network manager has solved all my issues.

Revision history for this message
Daniel Nilsson (daniel-dnil) wrote :

I reproduced this bug on 12.04.2 LTS yesterday, removing network manager solves the problem.

Changed in network-manager (Ubuntu):
status: Incomplete → Confirmed
Revision history for this message
Vla7 (vla7) wrote :

Same issue with the lates stable Ubunutu release. Please fix

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.