times out too early, stuck in PrepareForSleep, causing network and other services to not resume

[Steve Langasek]

After a suspend/resume, network-manager claimed that wireless was not available and would not let me reconnect to the wireless here. 'iwlist wlan1 scan' would also not work; so thinking that it was a driver problem, I rebooted the system. When it came back up, nm-applet in lightdm claimed that networking was disabled, and the option to enable it was greyed out. It could also not be enabled by nmcli. I ended up stopping network-manager, bringing up the interface via /etc/network/interfaces, and logging in... at which point, restarting network-manager *did* let me enable networking from my logged-in session.

So there are several problems here:
 - after a reboot, network-manager claimed networking was disabled.
 - nm-applet is not letting me enable networking from the lightdm session.
 - the networking was failing after a suspend/resume cycle, and could not be enabled even from inside the user session.

The last issue probably *was* a kernel driver problem; but the first two issues are network-manager problems of some kind.

SRU INFORMATION:
----------------
Reproducer:
- Force suspend to take very long by adding a sleep:
  echo -e '#!/bin/sh\nsleep 15\nexit 1' | sudo tee /usr/lib/pm-utils/sleep.d/00break
  (this will also make suspend fail, which eases testing)
- Suspend from the menu or with
  sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
- With the 13.10 final version, systemd-shim will (often) time out, and the next Suspend call from above will fail with "Operation already in progress" and the network does not come back up. With the fixed version, network should be back up and the Suspend() call can be issued many times.

Fix:
  https://github.com/desrt/systemd-shim/commit/136ed1143077d13c2
  https://github.com/desrt/systemd-shim/commit/16a7fdc0652ad78f4

Regression potential: Errors in this code could potentially break suspend/shutdown completely, so for verification both of these functionalities ought to be tested on real hardware.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: network-manager 0.9.8.0-0ubuntu8
ProcVersionSignature: Ubuntu 3.9.0-2.7-generic 3.9.3
Uname: Linux 3.9.0-2-generic x86_64
ApportVersion: 2.10.2-0ubuntu1
Architecture: amd64
Date: Sat May 25 21:38:31 2013
InstallationDate: Installed on 2010-09-24 (974 days ago)
InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
IpRoute:
 default via 192.168.1.1 dev wlan1
 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
 169.254.0.0/16 dev wlan1 scope link metric 1000
 192.168.1.0/24 dev wlan1 proto kernel scope link src 192.168.1.106
 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=false
 WirelessEnabled=true
 WWANEnabled=true
SourcePackage: network-manager
UpgradeStatus: Upgraded to saucy on 2013-05-06 (19 days ago)
WifiSyslog:

nmcli-con:
 Error: command ['nmcli', '-f', 'all', 'con'] failed with exit code 9:
 ** (process:11977): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files
 Error: nmcli (0.9.8.0) and NetworkManager (unknown) versions don't match. Force execution using --nocheck, but the results are unpredictable.
nmcli-dev: Error: command ['nmcli', '-f', 'all', 'dev'] failed with exit code 8: Error: NetworkManager is not running.
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 not running unknown unknown unknown unknown unknown unknown unknown

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Sameer Morar (smorar)]

A work around that works for me is killing the NetworkManager process using "sudo killall NetworkManager". The daemon re-starts and the network is restored.

[Jimmy Sjölund (jimmy-sjolund)]

Sameer Morar's workaround worked like a charm on my Ubuntu Studio 13.10.

[Evan Huus (eapache)]

I still see this fairly frequently, and it is strictly a network-manager problem. "sudo restart network-manager" causes it to reconnect gracefully without any problems or kernel magic.

I suspect a race condition, since it only happens about 1/3 of the time I suspend.

FWIW, I have a totally different network card (atheros).

[Evan Huus (eapache)]

First I ran "sudo stop network-manager" then ran "sudo NetworkManager --no-daemon --log-level=DEBUG >nm.log 2>&1" and then I reproduced the issue. I have attached the complete log output of network-manager from the initial receive of the "suspend" signal to the point I ctrl-C'ed it after experiencing this bug.

For context, this system has two ethernet ports (eth0, eth1) that had no attached cable during the experiment, and one atheros wifi card (wlan0) which was connected.

Hopefully something in here (or the lack of something in here) will be helpful.

[Tom Cameron (drdabbles)]

Not sure why my comment on my report of this bug didn't get merged into this one.

The work-around is to issue

nmcli nm sleep false

This tells NetworkManager to leave "sleep" mode. Restarting NetworkManager _happens_ to do this, but only by chance. I'd actually argue that restarting NetworkManager should _not_ reset sleep status, because you may actually want that to persist for lots of reasons over a restart.

[Evan Huus (eapache)]

Interesting, so it's not even a NetworkManager bug - whatever is supposed to be sending that signal to nm isn't sending it sometimes, or is sending it before nm can receive it or something?

[Dimitri John Ledkov (xnox)]

Maybe network-manager should ship shell snippet in pm-utils configuration directory to issue sleep false on resume/thaw?

[Ritesh Khadgaray (khadgaray)]

We can send such signals using pm-utils . Needs testing .

<xnox> ritz: right, so pm-utils package has direcotries with scripts that are executed on suspend/resume, hibernate/thaw.
<ritz> aah, thanks
<xnox> ritz: so network-manager or user should just add scripts there.
 ritz: see /usr/share/doc/pm-utils/README and /usr/share/doc/pm-utils/HOWTO.hooks.gz and etc.
 ritz: you can ship things in /usr/lib/pm-utils/sleep.d/ (for packages) or in /etc/pm/sleep.d (for administrator).
<xnox> I think.<xnox> ritz: yeap, see $ man 8 pm-suspend.

[Evan Huus (eapache)]

What component is *supposed* to be sending it that signal? I have noticed that in cases where this bug appears, other power management options also fail - trying to suspend again from the gear menu does nothing, I have to run pm-suspend from the cli. This indicates to me that some whole underlying subsystem is getting confused, and that other components may also need to be kicked - NetworkManager is just the most obvious one people notice right away.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

It looks like bug 1234469 might be a duplicate of this one.

[Evan Huus (eapache)]

Yes, looks like a dupe.

[Julien Olivier (julo)]

I had the exact same bug a few months ago. The issue was that NetworkManager is supposed to work with systemd, but Ubuntu chose to implement its own replacement to systemd instead (libsystemd-daemon0 I think). The issue I had previously was caused by libsystemd-daemon0 not sending the "resume" event to NetworkManager. I'd bet this is tre same issue here...

[Julien Olivier (julo)]

I've just found it: it's probably this bug: https://bugs.launchpad.net/ubuntu-gnome/+bug/1187005

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

While inspecting the logind D-Bus object I've noticed that "PreparingForSleep" is still set to "true" after the suspend/resume cycle.

$ gdbus introspect --system --dest org.freedesktop.login1 --object-path /org/freedesktop/login1

[KoRnKloWn (kornklown)]

Somebody marked this as a duplicate to bug 1234469, which simply isn't the case, bug 1234469 is a duplicate of this one (as others already stated), just look at the creation dates, this one is the original, so, people need to use launchpad correctly ;) And why is it that everyone (like me) has the power to delete/set duplicate status and other things???

Anyways, I fixed the duplicate status, removed it from this one and set bug 1234469 as a duplicate of this bug.

[Sicco van Sas (sicco)]

I can confirm that the command 'sudo nmcli nm sleep false' works as a temporary fix (it only works when running it using sudo).

[Pablo180 (paultait22)]

I'd just like to add that I have this problem, not on suspend (which I haven't tried since upgrading) but each and every time I resume from hibernate. I have to 'killall NetworkManager' to get networking back - every time.

nmcli nm sleep false - didn't work for me.

[Ian Nicholson (imnichol)]

On 10/22/2013 05:50 PM, Pablo180 wrote:
> I'd just like to add that I have this problem, not on suspend (which I
> haven't tried since upgrading) but each and every time I resume from
> hibernate. I have to 'killall NetworkManager' to get networking back -
> every time.
>
> nmcli nm sleep false - didn't work for me.
>
Did you run it with sudo?

[Pablo180 (paultait22)]

Ian, just checked and no I didn't! I'll try it again next resume.

[Craig Setera (craigjunk)]

I've just validated that

sudo nmcli nm sleep false

works for me after suspend

[Alfredo Pacheco Jr (alfredo-pacheco32)]

I am also having this issue after upgrading from Lubuntu 13.04 to 13.10. However, I have my power settings to just turn off the screen when my laptop is closed. Sleep and hibernate are disabled unless I manually select them from the logout menu. But the logout menu is having its own issues on another bug report.

The only solution for me is to run

sudo shutdown -P now
or
sudo reboot

I haven't tried:

sudo nmcli nm sleed false. Will attempt save my files, close my lid and see if this is a temp fix for me.

Toshiba Satellite A135-S4427

[Dan Gillmor (dan-gillmor)]

I'm also having issues with shutdown/reboot. Menu doesn't work at times;
have to run shutdown or reboot -- and even that doesn't always work.

On 10/23/2013 09:27 AM, Alfredo Pacheco Jr wrote:
> I am also having this issue after upgrading from Lubuntu 13.04 to 13.10.
> However, I have my power settings to just turn off the screen when my
> laptop is closed. Sleep and hibernate are disabled unless I manually
> select them from the logout menu. But the logout menu is having its own
> issues on another bug report.
>
> The only solution for me is to run
>
> sudo shutdown -P now
> or
> sudo reboot
>
> I haven't tried:
>
> sudo nmcli nm sleed false. Will attempt save my files, close my lid and
> see if this is a temp fix for me.
>
> Toshiba Satellite A135-S4427
>

--
Dan Gillmor
dangillmor.com/about
+1.650.868.7528

[Alfredo Pacheco Jr (alfredo-pacheco32)]

Ok. I closed my lid and quickly opened it back up. The network was disabled and I was unable to open it.

Running | sudo nmcli nm sleep false | does infact work as a temp fix.

[sdowney717 (sdowney717)]

I have found a serious issue now with the suspend.
The video card's fan (it is an x1300) will sometimes not spin up again!
I was using the PC and was getting video corruption then I looked down and the video fan is off.
It is free spinning so not stuck. I have the cover off as I was setting up 13.10 on the drive for another PC.

I can not use ubuntu if it is going to ruin my hardware. I certainly CAN NOT trust the suspend feature. It is totally random, sometimes following suspend the fan comes on, sometimes it does not.

[Mark Whitley (mark-k-whitley)]

I started experiencing this same problem immediately after upgrading to saucy. Happens like clockwork every time my netbook wakes from suspend.

Hardware: MSI WIND U230
Ubuntu version: 13.10
Network driver: rt2800pci

I found a workaround on this thread:
http://askubuntu.com/questions/362933/network-disabled-on-some-wake-ups-on-saucy-laptop

I was not able to use the "sudo service network-manager restart" fix because I do not have a 'network-manager' script in /etc/init.d/. I only have a 'networking' script and calling 'restart' on that locks up the system hard. I am able to use the "sudo killall NetworkManager" workaround.

[Catalin Hritcu (catalin-hritcu)]

General question: since Ubuntu seems to not support reverting dist-upgrades, is there any collection of packages I can restore to their pre 13.10 working state to avoid this horrible problem? (If not I'll seriously consider switching distribution; this is just too much)

[Pablo180 (paultait22)]

I don't know whether this means anything, but thought that it was worth mentioning. When using 13.04 I had previously had some problems with a kernel update and had gone back to using 3.8.0-30.44-generic. I noticed today however that despite upgrading to 13.10 several days ago, the kernel wasn't updated, I was still using 3.8.0-30.44-generic.

I manually updated to 3.11.0-12-generic, restarted, hibernated and resumed and networking was working fine. That's the first resume since upgrading in which networking has been working normally. I've since done it again to double check and it worked the second time too, so it looks like problem solved for me. Updating the kernel is the only change I have made today.

I don't know whether my problem is different to everyone else's, I only hibernate I don't suspend, but the same workarounds worked for me, so maybe this is relevant.

[sdowney717 (sdowney717)]

I created an executable desktop file. Click on it and network comes up for me
Single line in the file says " gksu restart network-manager". I think putting "gksu nmcli nm sleep false" would also work.

For my video card fan not respinning from suspend, I unplugged fan wire from video card board and hardwired to a system fan plug on the motherboard. Now it spins up everytime the system awakens.

[Ian Nicholson (imnichol)]

On 10/23/2013 11:27 AM, Alfredo Pacheco Jr wrote:
> Toshiba Satellite A135-S4427
That's funny, I have a Satellite L875D-S7111.

[Julien Olivier (julo)]

I occasionally have another suspend-related proble that might be related to this one somehow: after opening my lid, sometimes the laptop resumes, then suspends again automatically after a few seconds. If I then press the power button to resume again, it does the same again and again. And, after 3 or 4 suspend-resume loops, it finally settles down and resumes correctly. I guess some internal value is randomly stuck to the "suspended" state...

[Catalin Hritcu (catalin-hritcu)]

@Pablo180 (paultait22) #30: I'm already running 3.11.0-12-generic, so changing to that can't be the fix.

@Julien Olivier (julo) #33: I also have this probably related problem, and so far I found no workaround for that, other than trying to resume again and again until it eventually works. I've already mentioned this in one of the duplicates (1234469), but I'll repeat the log I get from systemd-logind for a case in which the first 3 resumes failed, but the fourth one succeeded.
Lid closed.
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Lid opened.
Operation finished.

Other problems I encountered that seem also related: sometimes the computer fails to suspend and sometimes even fails to shutdown. Everything worked fine before this crappy Ubuntu upgrade. I'm on a Dell Latitude 6400.

[little jo (littel-jo)]

Hello,

I have the same bug. But there is no problem of network if you activate XMIR.

[Pablo180 (paultait22)]

@Catalin you're right, it happened again. That is one in five resumes that the network fails to resume though, rather than every time like it did before, but still annoying.

[Sicco van Sas (sicco)]

I have the same problem as #33 (julo), where my laptop automatically goes back to suspend after waking up. I can reproduce this as follows:

I start up my laptop, suspend it the first time, wake it up again and I can work on it just fine (except for this bug causing me to have no internet connection). The second time I then suspend and wake up, my laptop will automatically go back to suspend within 30 seconds (whether I log in or not). This cycle then continues and I'm forced to reboot in order to fix it. Note that this happens whether I do or do not use temporary internet connection fix 'sudo nmcli nm sleep false'.

Is this bug related, or should I (and julo) start a new bug report?

[Alexander List (alexlist)]

I observed the same bug with current Saucy. Hardware is Lenovo TP x201 using iwlwifi.

After resume from suspend, networking is disabled. Enabling it in nm-applet has no effect.

[Dan Gillmor (dan-gillmor)]

This does work for me, every time:

sudo nmcli nm sleep false

On 10/24/2013 06:14 PM, Alexander List wrote:
> I observed the same bug with current Saucy. Hardware is Lenovo TP x201
> using iwlwifi.
>
> After resume from suspend, networking is disabled. Enabling it in nm-
> applet has no effect.
>

[Alfredo Pacheco Jr (alfredo-pacheco32)]

***UPDATE***
Yesterday morning I decided to re-install Lubuntu. I spent a good time prepping/reformatting an HDD to backup all the files I wanted to save.

I burned the Lubuntu 13.10 ISO in preparation to perform a fresh install seeing as how the upgrade from .04 to .10 had plagued me with many bugs. I rebooted, reformatted and partitioned the HDD and successfully installed Lubuntu 13.10.

As of now, 13.10 has been running with no issues. I did have the issue with Xfce4 power manager not running the first time, but that has since resolved itself.

I would also like to announce that network services resumes after I close and open the laptop. In power manager, I set my settings to "Do Nothing' when the lid is closed. The network icon does indicate no connection for a few seconds, but then restarts/resumes or establishes the saved WiFi connection.

This has resolved many issues that I have had and may work for others as well. Could I ask if anyone else having issues with the upgrade from 13.04 to 13.10 without a fresh install attempt a fresh install and also report if this solves the issue?

TOSHIBA SATELLITE A135-S4427
Lubuntu 13.10
3.11.0-12-generic (#19-Ubuntu SMP Wed Oct 9 16:12:00 UTC 2013)

[Matthew Babbs (matt-babbs)]

I have this problem, despite starting with a clean install.

However, I'm very rarely getting it since changing my disk setup: I moved /home off my netbook's main (very slow) SSD onto a separate SD card. I suspect that this has reduced demand on disk I/O, moving my netbook mostly beyond the theshold for the 'race condition' triggering this bug.

Formatting an HDD, as in Alfredo's comment #40, could have a similar effect on disk I/O speed. Might also explain why the bug wasn't spotted sooner, as devs tend to have faster PCs?

[Ing. Radomír Polách (exander77)]

I am also experiencing this bug. I wonder what is wrong with you to release Ubuntu when such a huge bug is present. The bug was alraedy reported like in May. I doesn't even work on clean install.

[hife (hife)]

I'm just going to list the symptoms I'm experiencing on Ubuntu 13.10 after most, but not all, sleep-resume cycles:

- Network Manager in sleep mode (fixable by executing: 'nmcli nm sleep false', works without sudo for me)
- System menu items for shutdown, reboot and sleep do nothing
   - Sleep mode possible with sudo pm-suspend
   - 'sudo shutdown now' is NOT working properly, but freezes at some point; I have not found a way to properly shut down my system. I'll go back and post the output I get when this happens, if that'll help.

I would like to know if there's a way to manually tell systemd to wake up. I have not been able to find a command for this in the manpages.

[Ing. Radomír Polách (exander77)]

I am reproducing similar symptoms as hife, but I have also problems with resuming bluetooth after suspend. Maybe the problem is unrelated.

[Dan Gillmor (dan-gillmor)]

I'm having the same issues. I'm most concerned at this point about the
inability to shut down properly.

On 10/27/2013 09:46 AM, hife wrote:
> I'm just going to list the symptoms I'm experiencing on Ubuntu 13.10
> after most, but not all, sleep-resume cycles:
>
> - Network Manager in sleep mode (fixable by executing: 'nmcli nm sleep false', works without sudo for me)
> - System menu items for shutdown, reboot and sleep do nothing
> - Sleep mode possible with sudo pm-suspend
> - 'sudo shutdown now' is NOT working properly, but freezes at some point; I have not found a way to properly shut down my system. I'll go back and post the output I get when this happens, if that'll help.
>
> I would like to know if there's a way to manually tell systemd to wake
> up. I have not been able to find a command for this in the manpages.
>

[Arild (arild-i)]

Contrary to #16 and the bug summary, for me PreparingForSleep is actually set to false when this occurs to me (at least this most recent time around). The commands and output below show how I observe this and wake Network Manager up.

[Jean-Marc (m-balthazar)]

Same problems here after suspend.

I use "sudo nmcli nm sleep false" to restore the connection, "sudo reboot" to reboot, "sudo shutdown -h now" to shutdown and "sudo pm-suspend" to suspend.

Regards.

[Id2ndR (id2ndr)]

After resuming, I got this bug. I tried $ sudo service networking restart => it crashed compiz. Apparently it seems to kill dbus but I don't know why. Am I the only one in this case ?

[Tong Sun (suntong001)]

Contrary to Alfredo Pacheco's announce, my Lubuntu 13.10 is a fresh install from downloaded ISO, after reformatted the HDD partition, yet I get the same problem: wired & wireless network was not available. That's why I'm here.

The 1st solution in the thread, killing the NetworkManager process using "sudo killall NetworkManager" works for me. I think executing: 'nmcli nm sleep false' would work as well.

[CBrider (zaknafien13)]

I am having similar issues with networking, and sometimes the sound card, and the video drivers. I also noticed that the time for this computer to boot, log-out, and log in is significantly (5-10 times) longer than it was when I was running 13.04. At first I had upgraded without a re-format. Today I re-installed after a reformat, and so far there have not been any videa or sound card issues, just the networking issue.

[Tong Sun (suntong001)]

I remember reading the following but it took me more than 3 rounds of careful reading to find it again. So, re-posting again:

Evan Huus (eapache) wrote:

> it's not even a NetworkManager bug - whatever is supposed to be
> sending that signal to nm isn't sending it (correctly...)
>
> I have noticed that in cases where this bug appears, other power
> management options also fail - trying to suspend again from the
> gear menu does nothing, I have to run pm-suspend from the
> cli. This indicates to me that some whole underlying subsystem is
> getting confused, and that other components may also need to be
> kicked - NetworkManager is just the most obvious one people
> notice right away.

I believe this is the most accurate description of the problem:

- it's not merely a NetworkManager bug
- the whole suspend/wake up mechanize is not working properly
- NetworkManager is just the most obvious one people notice right away

On my machine, Acer Aspire AS5536, if I close the lid then open & wake it up, my wired & wireless network will be gone. If I close the lid a second time, the machine won't even go to the suspend stage again.

[halfbeing (halfbeing)]

I am experiencing some of the same problems as reported by Hife above. The disabled network problem doesn't happen every time I wake my machine up, but on some of the occasions when it does I also find that sleep is disabled from the menu and from the function key, although I can still "sudo pm-suspend" from the terminal.

Rebooting from the Unity pull-down menu seems to be permanently disabled, regardless of whether networking or sleep are working, so I don't know if this is part of the same problem.

[Tong Sun (suntong001)]

The pm-utils and its configuration is fine, and maybe so of the network-manager.

I am able to further decouple the problem -- If I boot into text mode console, I am able to do "close the lid then open & wake it up" many many times without interruptting my wired & wireless network, while under Xorg (with fluxbox as WM), if I close the lid then open & wake it up, my wired & wireless network will be gone. If I close the lid a second time, the machine won't even go to the suspend stage again.

Conclusion: I think the problem has something to do with Xorg.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

The log files indicate that there is a problem with the D-Bus communication between systemd-logind and systemd-shim. Following entry is missing the systemd-shim log file:

========================================================================
GDBus-debug:Call:
 <<<< ASYNC COMPLETE org.freedesktop.DBus.RequestName() (serial 2)
      SUCCESS

[Martin Pitt (pitti)]

Something just crossed my mind: gnome-settings-daemon does some necessary things to work with logind's own lid switch/power button handling. Is any reporter here running Unity or GNOME who sees this? If not, then that would explain why I or my colleagues never see this, and it would be bug 1222021 (XFCE) or bug 1201180 (KDE). If this also happens under Unity or GNOME, then it's something else and most likely a race condition somewhere.

[Craig Setera (craigjunk)]

I was seeing this on Unity before I decided to roll back to my backed-up 13.04 installation.

[Evan Huus (eapache)]

Martin, I am seeing this regularly under Unity. Smells like a race condition to me.

[Catalin Hritcu (catalin-hritcu)]

I'm getting this with GNOME classic.

On Mon, Oct 28, 2013 at 4:19 PM, Evan Huus <email address hidden> wrote:
> Martin, I am seeing this regularly under Unity. Smells like a race
> condition to me.
>
> --
> You received this bug notification because you are subscribed to a
> duplicate bug report (1234469).
> https://bugs.launchpad.net/bugs/1184262
>
> Title:
> [logind] stuck in PrepareForSleep, causing network and other services
> to not resume
>
> Status in “network-manager” package in Ubuntu:
> Confirmed
> Status in “systemd” package in Ubuntu:
> Incomplete
>
> Bug description:
> After a suspend/resume, network-manager claimed that wireless was not
> available and would not let me reconnect to the wireless here.
> 'iwlist wlan1 scan' would also not work; so thinking that it was a
> driver problem, I rebooted the system. When it came back up, nm-
> applet in lightdm claimed that networking was disabled, and the option
> to enable it was greyed out. It could also not be enabled by nmcli.
> I ended up stopping network-manager, bringing up the interface via
> /etc/network/interfaces, and logging in... at which point, restarting
> network-manager *did* let me enable networking from my logged-in
> session.
>
> So there are several problems here:
> - after a reboot, network-manager claimed networking was disabled.
> - nm-applet is not letting me enable networking from the lightdm session.
> - the networking was failing after a suspend/resume cycle, and could not be enabled even from inside the user session.
>
> The last issue probably *was* a kernel driver problem; but the first
> two issues are network-manager problems of some kind.
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.10
> Package: network-manager 0.9.8.0-0ubuntu8
> ProcVersionSignature: Ubuntu 3.9.0-2.7-generic 3.9.3
> Uname: Linux 3.9.0-2-generic x86_64
> ApportVersion: 2.10.2-0ubuntu1
> Architecture: amd64
> Date: Sat May 25 21:38:31 2013
> InstallationDate: Installed on 2010-09-24 (974 days ago)
> InstallationMedia: Ubuntu 10.04.1 LTS "Lucid Lynx" - Release amd64 (20100816.1)
> IpRoute:
> default via 192.168.1.1 dev wlan1
> 10.0.3.0/24 dev lxcbr0 proto kernel scope link src 10.0.3.1
> 169.254.0.0/16 dev wlan1 scope link metric 1000
> 192.168.1.0/24 dev wlan1 proto kernel scope link src 192.168.1.106
> 192.168.122.0/24 dev virbr0 proto kernel scope link src 192.168.122.1
> MarkForUpload: True
> NetworkManager.state:
> [main]
> NetworkingEnabled=false
> WirelessEnabled=true
> WWANEnabled=true
> SourcePackage: network-manager
> UpgradeStatus: Upgraded to saucy on 2013-05-06 (19 days ago)
> WifiSyslog:
>
> nmcli-con:
> Error: command ['nmcli', '-f', 'all', 'con'] failed with exit code 9:
> ** (process:11977): WARNING **: Could not initialize NMClient /org/freedesktop/NetworkManager: The name org.freedesktop.NetworkManager was not provided by any .service files
> Error: nmcli (0.9.8.0) and NetworkManager (unknown) versions don't match. Force execution using --nocheck, but the results are unpredictable.
> nmcli-dev: Error: command ['nmcli', '-f', 'all', ...

[Sicco van Sas (sicco)]

@Martin (#59) I am also experiencing the bug under Unity.

[Julien Olivier (julo)]

I'm getting this all the time with GNOME Shell.

[Pablo180 (paultait22)]

I too am using Unity.

[Daniel Lombraña González (teleyinex)]

Hi,

I've also this problem. I upgraded yesterday to 13.10 and after suspend the network was gone. Then, I looked for the bug and I found it here. Applying the nmcli command fixes it, however, if I suspend the machine again and resume it, after few seconds it starts again to suspend without me doing anything, leaving the machine in an unusable state.

I think this is a big issue. How can I help?

[Daniel Lombraña González (teleyinex)]

Ohh, and I'm using Unity too.

[Catalin Hritcu (catalin-hritcu)]

@Daniel Lombraña González (teleyinex) #66
> however, if I suspend the machine again and resume it,
> after few seconds it starts again to suspend without me doing anything,
> leaving the machine in an unusable state.

Just try resuming again and again. For me this eventually works, but it sometimes takes 4-5 retries.

[Nick (c-nick)]

I'm using Lubuntu 13.10 on an HP G62 and also have this issue.

When mine wakes from suspend it comes back, then very quickly switches back to a bash screen with a few lines that don't appear for long enough for me to read, then goes back to whetever I was doing.

Sometimes it has network and sometimes it doesn't.

[Tong Sun (suntong001)]

I'm using gnome-settings-daemon with my fluxbox as WM, and I have this problem.

[Family5p (family5p)]

I am experiencing this bug after upgrade to Xubuntu 13.10 from Xubuntu 13.04.

- Network manager is often disabled after resume;

- The menu item for Suspend creates a `Do you want to suspend to RAM?' dialog, but after confirming, seems to only disable the Network manager (does not actually suspend the laptop);

- Log out->Restart from the menu logs me out but does not restart the laptop (shows the login screen instead).

- sudo pm-suspend works fine.

I am having to restart the newtork manager by running `sudo restart network-manager'

[Martin Pitt (pitti)]

Wrt comment 57:
> Conclusion: I think the problem has something to do with Xorg.

In particular, if other people can confirm this, it seems related to the logind inhibitor that gnome-settings-daemon sets so that logidn does not handle the lid event by itself. But as people also confirmed that this also happens with suspending from the indicator menu (not closing the lid), or even with a direct logind d-bus call, this can't be the whole story. Or we have independent bugs here. But let's dedicate this to the missing signal that Thaddaeus is currently investigating, as we have most data on that one so far.

[Martin Pitt (pitti)]

We have one theory what the problem could be (shim times out before finishing the method call). To test this, it would be great if affected people could install the systemd-shim version from my PPA: https://launchpad.net/~pitti/+archive/sru-test:

  sudo add-apt-repository ppa:pitti/sru-test
  sudo apt-get update
  sudo apt-get upgrade

  There are no other packages in it at the moment, so it's safe to upgrade. If you only want this specific package, grab one of these (depending on your architecture):

  https://launchpad.net/~pitti/+archive/sru-test/+files/systemd-shim_3%2Breal-0ubuntu1pitti1_i386.deb
  https://launchpad.net/~pitti/+archive/sru-test/+files/systemd-shim_3%2Breal-0ubuntu1pitti1_amd64.deb

and install with "sudo dpkg -i /path/to/downloaded/package/systemd-shim_*.deb".

Do you still get the problem with this? Does it behave any different?

[Deep Security (deepsecurity)]

Dear Martin,

I installed systemd-shim as you described. Nothing's changed.
I still need to restart my network to be able to online after coming back from lock or sleep.

Regards.

[Deep Security (deepsecurity)]

Dear Martin,

Actually after restarting my computer, everthing seemed fine to me.
I can easily come back from sleep and access to Internet without doing anything. I will be monitoring this 1 more day and let you know if everything is fine.

Thanks a lot for your helps.

[Shaw Terwilliger (sterwill)]

@Daniel Lombraña González (teleyinex) #66
> however, if I suspend the machine again and resume it,
> after few seconds it starts again to suspend without me doing anything,
> leaving the machine in an unusable state.

I get the same behavior on my Thinkpad T420. Sleep works great, but when I wake it up the network is disabled. When I re-enable NetworkManager ("nmcli nm sleep false"), the machine starts putting itself to sleep repeatedly.

Having to manually enable wifi is a small annoyance, but the repeating-sleep behavior is extremely annoying. It can take 5 minutes of waking it back up before I can use it.

[lebechec (lebechec)]

Sorry Martin, I installed systemd-shim (.deb) and nothing's changed (after reboot)

[Gabriel A. Devenyi (gadevenyi)]

For those who don't want to restart to fix the problem

sudo pkill NetworkManager

reliably fixes the problem

[Pablo180 (paultait22)]

Martin,

Thanks, I installed from the PPA and ran upgrade and then restarted, but on first resume afterwards networking was disabled. So it hasn't worked for me. Sorry.

[Gabriel A. Devenyi (gadevenyi)]

Installed PPA, updated, upgraded, restarted

Suspend -> Resume -> Networking Disabled

[Matthew Babbs (matt-babbs)]

Martin, the packages from your PPA seem to have fixed the problm on my netbook -- no problems with a several suspends. Closing lid, suspend from menu, or sleep key all seem to be OK.

WIll try on my desktop PC later as I've also been having the problem there.

I'd be happy to add some "before and after" log files if that would be helpful. Which log files would you want?

[guillaume ramelet (guillaume-ramelet)]

Martin, it seems to work as well on my netbook.
Will have to live several days with it to be 100% positive.

I was thinking to reinstall 13.04, you saved my week. Thank you very much

[Evan Huus (eapache)]

Martin, your package seems to have fixed the problem on my end (after four successful suspend/resume cycles, which would have been extremely unlikely previously).

Given that we don't have a consensus on whether the package works or not, we may have two interrelated issues at play. Yuck :(

[guillaume ramelet (guillaume-ramelet)]

Martin,
After closing the lid and being away for a couple of hours, I have just resumed :
the network is up. However 4-5 seconds after, the network is disconnected and it looks like it will fall in suspend again. An action on the touchpad seems to get it back from sleep, then the network is up again for good.

It is much better than before because when it happened, I had to hard stop or remove battery.
But there is still an issue with suspend state in 13.10. (maybe in another bug entry)

[Family5p (family5p)]

Martin,

I installed your package on Xubuntu 13.10.

- Network manager is ok after resume;

- I can now suspend the laptop from the menu;

- I can now restart the laptop from the menu.

However, one thing is now broken:

- previously the laptop would hibernate when the lid was closed, now it goes to sleep, despite `When the lid is closed' being set to `Hibernate' in the Power Manager settings. But `sudo pm-hibernate' works.

[Jean-Marc (m-balthazar)]

Martin,

Your solution works for me on a desktop running 13.10 with 3.11.0-13 kernel and Unity 7.1.2.

Thank you.

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

Family5p, for information regarding the broken lid event see bug 1222021 (Xfce).

[Catalin Hritcu (catalin-hritcu)]

For me Martin's package solves the problem ~96.6% of the time, which is already great progress since before I was having the problem almost every time. I've tried suspending my machine about 30 times (10 times by closing the lid, 10 times by clicking the suspend button in the menu, and 10 times with pm-suspend), and I got only one case when the network didn't come back. In the failing case the error reported by systemd-logind was slightly different than before (see #34 for the previous error message):
Lid closed.
Suspending...
Failed to send delayed message: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.
Lid opened.

I no longer encountered the case when resumption didn't work at all (machine going back to sleep as in #34). And it happened twice that pm-suspend wouldn't do anything (with output from systemd-logind).

Anyway, this is a step in the right direction, I would say :)

[Vladimir (vladimir-l)]

Hi Martin,

installing "systemd-shim" from your PPA seems to solve my problem, at least I do not experience the problem at the moment

Thanks a lot!
vladimir

[Id2ndR (id-2ndr)]

systemd-shim_3+real-0ubuntu1pitti1 solve the network trouble after resuming for me too.

[Pablo180 (paultait22)]

Martin,

I previously said that your fix didn't work for me, but other than the first suspend after a reboot and subsequent resume in which networking was disabled, every other suspend and resume cycle (and also hybrid and hibernate) has come back with the network working fine again after resuming. Perhaps five or six times in a row now without problem. However I shall keep my eye on it and see if this has fixed the problem permanently. Thanks.

[Ian Nicholson (imnichol)]

On 10/30/2013 04:59 AM, Martin Pitt wrote:
> We have one theory what the problem could be (shim times out before finishing the method call). To test this, it would be great if affected people could install the systemd-shim version from my PPA: https://launchpad.net/~pitti/+archive/sru-test:
>
> sudo add-apt-repository ppa:pitti/sru-test
> sudo apt-get update
> sudo apt-get upgrade
>
> There are no other packages in it at the moment, so it's safe to
> upgrade. If you only want this specific package, grab one of these
> (depending on your architecture):
>
> https://launchpad.net/~pitti/+archive/sru-test/+files/systemd-shim_3%2Breal-0ubuntu1pitti1_i386.deb
> https://launchpad.net/~pitti/+archive/sru-test/+files/systemd-shim_3%2Breal-0ubuntu1pitti1_amd64.deb
>
> and install with "sudo dpkg -i /path/to/downloaded/package/systemd-
> shim_*.deb".
>
> Do you still get the problem with this? Does it behave any different?
>
> ** Package changed: network-manager (Ubuntu) => systemd-shim (Ubuntu)
>
> ** Changed in: systemd-shim (Ubuntu)
> Status: Confirmed => Incomplete
>
This seems to have resolved the bug for me as well.

[Rafael Levi (rlevi66)]

Hi Martin,
I tryed twice and after fool reboot and it didn't work for me. Still the network is disabled after resume from suspend.

Cheers,

Rafi

[Family5p (family5p)]

Just to say that I installed Martin's shim package, and, following Thaddäus's comment, applied a suggested workaround for a (perhaps unrelated) Xfce bug 1222021. As of now I do not see any of the earlier problems recur.

[Daniel Lombraña González (teleyinex)]

Hi,

I've installed Martin's package, and after a reboot, if I suspend the laptop the result is exactly the same: no wifi at all.

However, the if I run pm-suspend with a fresh restart it works like a charm (even without Martin's package), so obviously there is something messing with the suspend mode from Unity or something similar.

[Shaw Terwilliger (sterwill)]

I installed Martin's package, but it doesn't fix the issue on my Thinkpad T420. After resume, the network isn't usable and I have to run "nmcli nm sleep false" to enable it.

[bruper (bruper59)]

Hi Martin,
I tryed and after reboot, it don't work for me.
Still the network is disabled after resume from suspend.
:-(

[Tommy Trussell (tommy-trussell)]

I just added Martin Pitt's sru-test PPA and have been through several suspend/resume cycles. So far so good. It will take several hours to be sure this solves it, though.

QUESTION (is this the same issue?): About the same time the network fails (sometimes before sometimes after) I also notice I cannot use the "gear" panel menu in Unity to shut down, restart, or log out. The Shutdown/Restart or logout dialog usually comes up and I can click the shutdown or restart or logout button, but nothing happens, or at least not within the few tens of seconds I have waited. I usually resort to a VT or terminal window and a "sudo reboot" or "sudo shutdown -h now" command.

If this is a separate issue I will search for a different bug, but since I am also experiencing the loss of networking AND this bug has been applied to logind I presume I might be seeing a manifestation of the same problem. I'm also experiencing some other Unity flakiness that I associate (rightly or wrongly) with the same issues.

[Jürgen (jurgen-depicker)]

Same for me: the ppa did the thing ( i also applied the workaround mentioned in #10 though). I'm using ub!ntu gnome - after resume, i'm no longer asked for a password?! Anyone alse with this issue?

[Evan Huus (eapache)]

For fun (having read the changelog of Martin's shim package) I overloaded my system so much that suspend took slightly over a minute to complete, at which point I was able to reproduce the same failure as before installing the updated shim package. I have not otherwise experienced the problem (in numerous tests) since installing the updated shim.

This indicates conclusively that at least in my case, the timeout/race is the culprit. It also suggests a way that Martin (or another dev) might be able to reproduce. Find an older/weaker system, launch some VMs and start some compiles, and then run a suspend. Hopefully that will be enough to trigger it.

[Ronald (ronald645)]

I'm assuming that I'm suffering from the same symptom. Packages from comment #73 fixed it after I manually resetted NetworkManager with nmcli.

I think that the comment #16 is mentioning the root cause of all this.

Possibly related bug: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1196752

[Tommy Trussell (tommy-trussell)]

UPDATE 1: regarding my question in comment #98: I read through the existing comments again and I see the non-functioning Shut Down, Restart, and Log Out menus ARE listed in comment #44.

UPDATE 2: I have been using the updated package Martin Pitt described in comment #73 and have NOT seen the bug through several dozen sleep/resume cycles under full load.

As others have commented, the problem is triggered under heavy system load. This netbook is an Acer Aspire One D260 with a 1.66Ghz dual-core Intel Atom N450 processor and Intel graphics, so opening Chrome with a couple of dozen tabs, Thunderbird, Firefox, DropBox, Ubuntu One PLUS a few more apps (as I am wont to do) is definitely a bit of a strain on the hardware. ;-)

[Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount)]

logind is waiting for systemd-shim to finish the actual suspend/resume progress, but the D-Bus connection will timeout, If the whole suspend/resume cycle takes longer than 30 sec. In this case logind reverts back to normal mode (PreparingForSleep = false), but the signal to inform clients like network-manager about the state change does not get emitted.

[Pablo180 (paultait22)]

I'd just like to echo what some other have said regarding Martin's PPA. It has improved things, but it hasn't fixed it. I now have about one resume a day where networking is disabled and won't come back without the workarounds above, it was previously about 50/50. This is out of about 10 resume a day. I am not sure whether this is related but the one that fails tend to be the first resume of the day, with the laptop being hibernating overnight (at least for two days running now so could still be coincidence).

[tophill (tp)]

This seems to have fixed an annoying problem for me, thank you very much. Network OK after every suspend so far.

In case others have this, I noticed another problem since upgrade to 13.10. Sound settings output device is not saved. On reboot It defaults to wrong choice. After being reset manually, it works fine. Didn't spot this in bug reports.

[Giuseppe (giusepm)]

Hi! Martin's PPA didn't fix for me!

[Duarte Gomes (dnunogomes)]

replaced the package as told in commment #73. Now i can suspend and resume several times with NetworkManager sorting things out good. it worked , thanks.

[Emil Maric (emil-maric)]

Martin's package didn't fix it for me.

I'd also like to add that it seems Ubuntu's behavior has changed with regards to "Suspending". In earlier versions, my computer would be put to sleep after I pressed suspend. Now it just seems to take me to the log in screen, without turning off my display. Once I log back in, my display is turned off within 5 seconds. I then press "Enter", and it resumes normally.

[Martin Pitt (pitti)]

Thanks everyone for testing! So it seems this fixes the issue for about half the people. The others have a different bug which breaks suspend similarly, but for a different reason. We need a new bug report for this then, with a D-BUS monitor log during suspend (https://wiki.ubuntu.com/DebuggingDBus).

[Martin Pitt (pitti)]

Note to Ryan and myself: For the final fix we should not just make the timeout longer, as that would still cause a resume failure when suspending for more than 10 minutes (in my PPA case), but completely disable the timeout while a method call is being executed. That might help for a few more people here (or perhaps even most of them).

[Rafael Levi (rlevi66)]

I wasn't sure what output you need so I add the whole dbus-monitor output. The system went to suspend and woke up but the network stayed disabled. Killall NetworkManager did the trick.

[Guido Do (guido-dornbusch)]

attaching a dBus log from a suspend.

I also have the missing network connection issue - in addition after wake from suspend the graphic is corrupted in addition in my case. A forced reboot (ctrl-alt-delete in F1 terminal) reboots and the network is not even available.

Non of these instruction works in this case
- nmcli nm sleep false
- sudo service network-manager restart
- sudo killall NetworkManager

Only complete switching off the Desktop power supply for several seconds an rebooting afterwards helps to recover network.

no problems with 13.04 and all older version on this machine.

[Shaw Terwilliger (sterwill)]

In my previous comment I said that Martin's package didn't fix my issue, but two days after I said that, the suspend-repeat loop seems to have gone away. Sometimes my wifi turns on automatically on resume, sometimes it doesn't.

Overall, it's a much better experience, but there's still some work to do. Thanks, Martin!

[Paul Smedley (paul-smedley)]

Comment in #73 seems to have fixed things for me too

[Martin Pitt (pitti)]

Hello Rafael,

Rafael Levi [2013-11-04 22:45 -0000]:
> I wasn't sure what output you need so I add the whole dbus-monitor
> output.

That was the session D-BUS, though. Sorry if I was unclear, you need
to follow the "system bus" recipe on https://wiki.ubuntu.com/DebuggingDBus .

[Martin Pitt (pitti)]

Hello Guido,

Guido Do [2013-11-04 22:49 -0000]:
> attaching a dBus log from a suspend.
>
> I also have the missing network connection issue

Did that happen after the particular suspend you monitored with your
log? That did have the "PrepareForSleep False" signal which was
otherwise missing. However, your D-BUS log is incomplete (only
signals, no method calls), you need to follow the "system bus" recipe
on https://wiki.ubuntu.com/DebuggingDBus

> - in addition after
> wake from suspend the graphic is corrupted in addition in my case.

That's a different bug, I'm afraid.

[b3nmore (b3nmore)]

Finally I could reproduce this issue, even with systemd-shim from #73 installed. Attached is the system dbus monitor log of a hibernate/resume cycle, where nm wasn't awoke.

It seems to me , that (at least in my case) the duration of the hibernation period plays a role, i.e. I could only reproduce it, if resume takes place a few hours after hibernation.

[b3nmore (b3nmore)]

I ran another hibernate/resume cycle directly after the failed cycled documented in the previous post, leaving nm in its unconnected state. After resume, nm managed to connect to my wifi as it should.

[Duke (duke1995)]

Here's another D-Bus system bus monitoring log. I followed the instructions at https://wiki.ubuntu.com/DebuggingDBus#How_to_monitor_the_system_bus (see also: https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/116)

After suspending and resuming networking was not working. I had to execute 'sudo nmcli nm sleep false' in order to get the networking working again.

The only fix I have applied up to now is the one I found at http://www.webupd8.org/2013/01/fix-wireless-or-wired-network-not.html

Aside: It seems that when I run 'nmcli nm sleep false' as a non-sudo user, the networking starts working again, but afterwards I am unable to suspend/restart/shutdown from the session menu.

[Emil Maric (emil-maric)]

Hi Martin,
I've attached a system D-bus log for when I go into an come back from suspend.

I just wanted to add that it takes about 20 seconds for my laptop to fully complete going into suspend. This never happened prior to 13.10.

[Martin Pitt (pitti)]

b3nmore [2013-11-07 18:20 -0000]:
> It seems to me , that (at least in my case) the duration of the
> hibernation period plays a role, i.e. I could only reproduce it, if
> resume takes place a few hours after hibernation.

Indeed, the cutoff point would be 10 minutes (that's the timeout of
the current PPA version). As I wrote, that's just an experimental one
which confirms that this is the problem. The real solution is to
completely disable the timeout until a method call is fully done.

[b3nmore (b3nmore)]

> Indeed, the cutoff point would be 10 minutes (that's the timeout of
> the current PPA version). As I wrote, that's just an experimental one
> which confirms that this is the problem. The real solution is to
> completely disable the timeout until a method call is fully done.

That was my first thought too, when trying to find reproducible conditions. But in my case 30 minutes are definitive not long enough (just tested it). I would even say the hibernation period must be longer than 1h (not tested thoroughly).

Btw, at which point in the hibernation/resume cycle does the timeout start counting?

[Tin Tvrtkovic (tinchester)]

I'm affected by this problem and I'd like to help. Are you still collecting system DBus logs?

[Martin Pitt (pitti)]

Tin Tvrtkovic [2013-11-08 8:56 -0000]:
> I'm affected by this problem and I'd like to help. Are you still
> collecting system DBus logs?

Not for now, thanks. The recent logs pretty much all agree that the
PrepareForSleep(false) signal is missing.

[Duke (duke1995)]

I am glad to see a fix has been committed for Trusty, I hope the same fix will be applied soon for Saucy too (for the moment the bug has not been assigned for Saucy yet).
Thanks a lot in advance.

[Martin Pitt (pitti)]

I uploaded systemd-shim 4 to trusty, and to the saucy-proposed SRU review queue.

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd-shim - 4-0ubuntu1

---------------
systemd-shim (4-0ubuntu1) trusty; urgency=low

  * New upstream release:
    - Flush bus before exiting on idle to avoid a race where a message is
      queued up but not yet sent. (LP: #1184262, part 1)
    - Adjust the definition of "inactivity" to be 10 seconds after done
      processing the last request instead of 10 seconds after we started.
      This matters for long-running tasks like suspend. (LP: #1184262, part 2)
    - Don't exit-on-idle while shutting down to avoid losing the flag that
      tells us we are in the middle of a shutdown. (Necessary, but not
      sufficient for LP #1211514)
 -- Martin Pitt <email address hidden> Tue, 12 Nov 2013 09:31:19 +0100

[Martin Pitt (pitti)]

For our friends on 13.10, I updated my PPA (https://launchpad.net/~pitti/+archive/sru-test) to have systemd-shim version 4, so you can test it now. I also pinged the SRU team, but accepting into -proposed might still take a day or two.

[Gabriel A. Devenyi (gadevenyi)]

This bug isn't fixed, I still lose network on suspend/resume when installing the latest systemd-shim from the linked PPA.

[Pablo180 (paultait22)]

Have to agree with Gabriel #129. I installed the latest version from PPA yesterday and restarted, but today I also lost network on resume again.

[Martin Farrell (fazzuk)]

Thanks Martin for all your efforts on this bug. You're PPA has totally fixed the bug for me on 13.10.

Sorry to hear its not working for everyone.

[A. Richard Miller (themillers)]

Big thanks from me, too, Martin Pitt!

I installed your PPA on my Ubuntu 13.10/Acer AO722 netbook about eight hours ago, and have exercised it quite a bit. As with Martin Farrell, your PPA seems to have totally fixed my Suspend failures. (They began with the beta of Ubuntu 13.10; see my comments in the parallel bug 1027202.)

Here's hoping all affected Ubuntu users can breathe this sigh of relief, real soon now.

[Brian Murray (brian-murray)]

Hello Steve, or anyone else affected,

Accepted systemd-shim into saucy-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/systemd-shim/4-0ubuntu0.13.10 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, and change the tag from verification-needed to verification-done. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Rafael Levi (rlevi66)]

systemd-shim_4-0_ubuntu0.13.10 didn't fix the problem for me.

[Martin Pitt (pitti)]

Rafael, thanks for testing. We know that this update does not fix the problem for everyone, but it seems to fix it for half/most of the reporters here. So may I ask for only declaring this verification-failed if you see a regression, i. e. if this version makes it worse than before? After you get this update, and we can exclude that particular failure mode, we need a new bug report (as this has grown way too big and noisy with too many subscribers, and this particular root cause has been understood and fixed), where we do a new round of debugging and log collection. Thank you!

[Peng (pengwg)]

Unfortunately my problem wasn't fix either using saucy proposed. Looking forward to a new bug report.

[Philipp Keck (philipp-v)]

Doesn't work for me either. I installed "systemd-shim/saucy-proposed", rebooted, suspended, waited 15 minutes and turned it on again -> wifi didn't work. "sudo killall NetworkManager" still solves the problem, so no regression.

[Rafael Levi (rlevi66)]

Hi,
I understand that it's difficult to deal with several bugs that look the
same. Before I file a new bug. Is there anything I can do to distinguish
the bug I have from the solve one? They have the same symptoms.
Rafael.
On Nov 14, 2013 10:31 PM, "Martin Pitt" <email address hidden> wrote:

> Rafael, thanks for testing. We know that this update does not fix the
> problem for everyone, but it seems to fix it for half/most of the
> reporters here. So may I ask for only declaring this verification-failed
> if you see a regression, i. e. if this version makes it worse than
> before? After you get this update, and we can exclude that particular
> failure mode, we need a new bug report (as this has grown way too big
> and noisy with too many subscribers, and this particular root cause has
> been understood and fixed), where we do a new round of debugging and log
> collection. Thank you!
>
> ** Tags removed: verification-failed
> ** Tags added: verification-needed
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1184262
>
> Title:
> times out too early, stuck in PrepareForSleep, causing network and
> other services to not resume
>
> Status in “systemd” package in Ubuntu:
> Invalid
> Status in “systemd-shim” package in Ubuntu:
> Fix Released
> Status in “systemd” source package in Saucy:
> Invalid
> Status in “systemd-shim” source package in Saucy:
> Fix Committed
> Status in “systemd” source package in Trusty:
> Invalid
> Status in “systemd-shim” source package in Trusty:
> Fix Released
>
> Bug description:
> After a suspend/resume, network-manager claimed that wireless was not
> available and would not let me reconnect to the wireless here.
> 'iwlist wlan1 scan' would also not work; so thinking that it was a
> driver problem, I rebooted the system. When it came back up, nm-
> applet in lightdm claimed that networking was disabled, and the option
> to enable it was greyed out. It could also not be enabled by nmcli.
> I ended up stopping network-manager, bringing up the interface via
> /etc/network/interfaces, and logging in... at which point, restarting
> network-manager *did* let me enable networking from my logged-in
> session.
>
> So there are several problems here:
> - after a reboot, network-manager claimed networking was disabled.
> - nm-applet is not letting me enable networking from the lightdm
> session.
> - the networking was failing after a suspend/resume cycle, and could
> not be enabled even from inside the user session.
>
> The last issue probably *was* a kernel driver problem; but the first
> two issues are network-manager problems of some kind.
>
> SRU INFORMATION:
> ----------------
> Reproducer:
> - Force suspend to take very long by adding a sleep:
> echo -e '#!/bin/sh\nsleep 15\nexit 1' | sudo tee
> /usr/lib/pm-utils/sleep.d/00break
> (this will also make suspend fail, which eases testing)
> - Suspend from the menu or with
> sudo gdbus call -y -d org.freedesktop.login1 -o
> /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
> - With the 13.10 final version...

[Horst Schirmeier (horst)]

systemd-shim 4-0ubuntu0.13.10 from saucy-proposed solved the problem for me. Thanks for your bug-hunting efforts!

[Martin Pitt (pitti)]

Rafael Levi [2013-11-15 19:44 -0000]:
> I understand that it's difficult to deal with several bugs that look the
> same. Before I file a new bug. Is there anything I can do to distinguish
> the bug I have from the solve one?

For one, if the -proposed package didn't help then that's a strong
indication that it's a different bug. I suggest with the proposed
package installed, you create a D-BUS system monitor log
(https://wiki.ubuntu.com/DebuggingDBus) and attach it to a new bug.
Just start with "apport-bug systemd-services", we'll figure out along
the way which package it really belongs to.

Thanks!

[Gabriel A. Devenyi (gadevenyi)]

As per comment #140, I have submitted a new bug #1252121 with Dbus logging.

[Martin Pitt (pitti)]

Can we please get some more people to test this, so that this can be released into -updates soon? Both "it fixed my problem" and "I still have the problem, but the update does not make it worse" are appreciated. And of course, if this update makes it worse, this would be a showstopper and we definitively need to hear about it (although the nature of the patch makes that very unlikely).

[Catalin Hritcu (catalin-hritcu)]

This doesn't make it worse for me, it makes it better, but it still doesn't completely solve the network failing to resume problem. As with the first patch I get a failure rate of around 1 in 30. I've tried suspending 30 times in 3 different ways: using the lid, using "sudo pm-suspend" and the menu or the power button menu. The X below shows the failure :)

lid: ||||| X||||
pm-suspend: ||||| |||||
menu/power button: ||||| |||||

The failure case was solved by running "nmcli nm sleep false".

[Julien Olivier (julo)]

As for me, that completely fixes the problem. Thanks!

[Martin Pitt (pitti)]

Hello Catalin,

thanks for your feedback!

Catalin Hritcu [2013-11-19 8:17 -0000]:
> lid: ||||| X||||
> pm-suspend: ||||| |||||
> menu/power button: ||||| |||||

Interesting, thanks for pointing that out. If it can be confirmed that
this now only happens if you close the lid, then this indeed deserves
a new bug report, or perhaps it's the same issue as Gabriel has in bug
1252121. I'll ask there, too.

It would also be interesting if you ever get a suspend failure with
this:

  sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true

This should ideally be equivalent to running pm-suspend or the
menu/power button, but it is only sometimes equivalent to closing the
lid. The lid is handled by logind internally *unless* there is a
running Unity/GNOME session. On some laptops there are pm-suspend
quirks which switch to VT1 before suspend, which might be related.

[Catalin Hritcu (catalin-hritcu)]

I'll try this experiment and report in the next 24 hours then. It takes quite a bit, and I'll try to get a larger number of repeats.

[Philipp Keck (philipp-v)]

I don't have the time to repeat the experiments, however in my case it seems to be pretty deterministic: None of the suggested ways works (menu, pm-suspend, the other command or lid-close, which i usually do).

[Martin Pitt (pitti)]

Philipp Keck [2013-11-19 10:11 -0000]:
> I don't have the time to repeat the experiments, however in my case it
> seems to be pretty deterministic: None of the suggested ways works
> (menu, pm-suspend, the other command or lid-close, which i usually do).

If even "sudo pm-suspend" does not work, then this isn't related to
logind/systemd-shim at all, and you seem to have an entirely different
bug. Presumably the network driver which does not get along with
suspend?

[Matthew Babbs (matt-babbs)]

The fix in -proposed repo makes the situation much better for me. Both my desktop and netbook, which were hitting the bug every suspend, now show it only occasionally -- as in, it may happen once every few days.

I presume that's from a different cause so I'll try to get logs for bug #1252121 next time it happens.

[Martin Pitt (pitti)]

Thanks everyone for testing and your patience! We got sufficiently many verification results now. Let's move this to -updates after the 7 days are over, and close this bug report which already got way out of hand. Remaining network failures after resume should be discussed on bug 1252121, I left some debugging questions there.

[Martin Pitt (pitti)]

For the record: anyone who is still affected by this particular symptom (network not coming up after suspend), please subscribe to and have a look at bug 1252121. I put a fix into my https://launchpad.net/~pitti/+archive/sru-test PPA (systemd-shim version 5-0ubuntu0.0pitti1). This is the only package in the PPA, so it's safe to just dist-upgrade. This really ought to fix this problem properly. Please let me know positive and negative results in bug 1252121.

If you have another suspend problem (some people reported that suspend takes very long), please file a new bug.

Thanks!

[Launchpad Janitor (janitor)]

This bug was fixed in the package systemd-shim - 4-0ubuntu0.13.10

---------------
systemd-shim (4-0ubuntu0.13.10) saucy-proposed; urgency=low

  * New upstream release:
    - Flush bus before exiting on idle to avoid a race where a message is
      queued up but not yet sent. (LP: #1184262, part 1)
    - Adjust the definition of "inactivity" to be 10 seconds after done
      processing the last request instead of 10 seconds after we started.
      This matters for long-running tasks like suspend. (LP: #1184262, part 2)
    - Don't exit-on-idle while shutting down to avoid losing the flag that
      tells us we are in the middle of a shutdown. (Necessary, but not
      sufficient for LP #1211514)
 -- Martin Pitt <email address hidden> Tue, 12 Nov 2013 09:31:19 +0100

[Brian Murray (brian-murray)]

The verification of the Stable Release Update for systemd-shim has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Anton Statutov (astatutov)]

I still have this issue. The system is up-to-date.

My network controller:
44:00.0 Network controller: Broadcom Corporation BCM4312 802.11b/g LP-PHY (rev 01)

Linux kernel:
Linux stant-laptop 3.11.0-14-generic #21-Ubuntu SMP Tue Nov 12 17:07:40 UTC 2013 i686 i686 i686 GNU/Linux

Package version:
ii systemd-shim 4-0ubuntu0.13.10

Can someone hint me what have I missed?

[penalvch (penalvch)]

Anton Statutov, if you still have this issue, than this report doesn't cover your problem as it is marked Fix Released. Please file a new report via a terminal:
ubuntu-bug systemd-shim

[Martin Pitt (pitti)]

Andon: Please see https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/151

[Daniel Lombraña González (teleyinex)]

This bugs keeps affecting me even with the latest version. Can I do something to get this fixed?

[penalvch (penalvch)]

Daniel Lombraña González, Please see https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/151 .

[Sergei Solo (solomatkins)]

In latest version of Ubuntu 14.04 this bug not fixed!
I can't enable wireless networking after my laptop resumed from suspend.

p.s. suspend turning with some errors too:
1) It take more time (in Ubuntu 12.04 laptop suspend faster)
2) before display turns off and laptop become full suspended - I see Ubuntu lock screen and hear Ubuntu notice sound.

[Sergei Solo (solomatkins)]

Bug report here: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1295285

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1184262

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Carlos A. (cif2cif)]

ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: cif 2063 F.... pulseaudio
CurrentDesktop: Unity
DistroRelease: Ubuntu 14.04
HibernationDevice: RESUME=UUID=78205ef1-1270-4794-b8c5-647151a38a07
InstallationDate: Installed on 2014-04-15 (16 days ago)
InstallationMedia: Ubuntu 14.04 LTS "Trusty Tahr" - Beta amd64 (20140326)
MachineType: Dell Inc. Dell System XPS L322X
Package: linux (not installed)
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.13.0-24-generic root=UUID=457285fa-1fe0-4723-88de-4f3c0a9aaebe ro video=eDP1:d quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
RelatedPackageVersions:
 linux-restricted-modules-3.13.0-24-generic N/A
 linux-backports-modules-3.13.0-24-generic N/A
 linux-firmware 1.127
Tags: trusty trusty trusty
Uname: Linux 3.13.0-24-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare scanner sudo
_MarkForUpload: True
dmi.bios.date: 01/22/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A07
dmi.board.name: 0WG38X
dmi.board.vendor: Dell Inc.
dmi.board.version: A00
dmi.chassis.type: 8
dmi.chassis.vendor: Dell Inc.
dmi.chassis.version: 0.1
dmi.modalias: dmi:bvnDellInc.:bvrA07:bd01/22/2013:svnDellInc.:pnDellSystemXPSL322X:pvr:rvnDellInc.:rn0WG38X:rvrA00:cvnDellInc.:ct8:cvr0.1:
dmi.product.name: Dell System XPS L322X
dmi.sys.vendor: Dell Inc.

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[Carlos A. (cif2cif)]

apport information

[penalvch (penalvch)]

Joao Natali / Carlos A., please do not add bug tasks nor apport collect to this report, as it is closed. If you are having a bug in Ubuntu, so your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Anton Statutov (astatutov)]

Christopher M. Penalver, Carlos A., there is already a continuation of this bug #1252121.

[sayth (flebber-crue)]

This bug exists in 14.04. I can manually reconnect to wireless by typing

sudo service network-manager restart

[Yanpas (yanpaso)]

Have somebody tried to install the latests kernel versions? Will it fix the trouble?

[Pavel Roskin (proski)]

I'm on fully up-to-date Ubuntu 14.04 with the latest kernel 3.13.0-36-generic, and I got this error. I have a Lenovo ThinkPad W530. I use it either with the internal monitor or with an external monitor connected to displayport. I don't remember what I did today. I think I connected the display cable, closed the lid and then logged in. I do it every day, but something must have been slightly different today.

I got "network disabled". I clicked on "Enable Networking" several times, but it didn't help. There was no error message and no change in the menus shown on left-click or right-click on the nm-applet.

This didn't work:

# service network-manager restart
stop: Unknown job: network-manager
start: Unknown job: network-manager

This worked:

# nmcli nm
RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
running asleep enabled enabled enabled enabled
# nmcli nm sleep false

nm-applet should show the sleep state and should wake up NetworkManager if requested by the user.

Ideally, it would be great not to put the network to sleep if the computer is not going to sleep. And the computer should not go to sleep if the lid is being closed but there is a display connection.

[Alberto Salvia Novella (es20490446e)]

@ madmin314:

If you are sure this is a security bug, please:

 1. Explain why do you think so.
 2. Mark it as "Public Security" again.

[Pavel Roskin (proski)]

I got the problem with "sleeping network" again. This time I'm absolutely sure I wasn't doing anything that could provoke the sleep. The computer was with the lid closed, HDMI connected to the external monitor. I left for lunch. When I returned. the network was "sleeping", the crescent shaped LED on the lid was blinking.

The last messages from "dmesg -T":

[Thu Sep 11 07:57:39 2014] type=1400 audit(1410436608.790:58): apparmor="STATUS" operation="profile_replace" profile="unconfined" name="/usr/sbin/cupsd" pid=12685 comm="apparmor_parser"
[Thu Sep 11 10:14:42 2014] perf samples too long (2523 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
[Thu Sep 11 12:13:22 2014] PM: Syncing filesystems ... done.
[Thu Sep 11 12:13:22 2014] PM: Preparing system for mem sleep

I was away at 12:13.

[Chris Morris (chriswillmorris)]

I am on Ubuntu 14.04 and am still experiencing this issue.

[penalvch (penalvch)]

Chris Morris, if you are experiencing an issue still, then this bug report had nothing to do with your problem. Please file a new report.

[Pablo180 (paultait22)]

There's no need to file another bug report, it will only be marked as a duplicate. This bug has not been fixed for everyone and continues on here:-
https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1252121

[Jan Schürmann (visionfactory.net)]

still present in Xenial