Network does not come up after resuming from suspend.

Bug #1234469 reported by Ian Nicholson
524
This bug affects 113 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Incomplete
Medium
Unassigned
systemd-shim (Ubuntu)
Incomplete
Undecided
Unassigned

Bug Description

When my computer wakes up from being suspended, the wireless network connection doesn't come back up.
I'm able to fix the problem by running "nmcli nm sleep false", which causes the wireless card to reconnect.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: network-manager 0.9.8.0-0ubuntu21
ProcVersionSignature: Ubuntu 3.11.0-8.15-generic 3.11.1
Uname: Linux 3.11.0-8-generic x86_64
NonfreeKernelModules: fglrx
ApportVersion: 2.12.5-0ubuntu1
Architecture: amd64
Date: Wed Oct 2 20:21:33 2013
EcryptfsInUse: Yes
IfupdownConfig:
 # interfaces(5) file used by ifup(8) and ifdown(8)
 auto lo
 iface lo inet loopback
InstallationDate: Installed on 2013-08-09 (54 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
IpRoute:
 default via 192.168.125.1 dev wlan0 proto static
 192.168.125.0/24 dev wlan0 proto kernel scope link src 192.168.125.8 metric 9
MarkForUpload: True
NetworkManager.state:
 [main]
 NetworkingEnabled=true
 WirelessEnabled=true
 WWANEnabled=true
 WimaxEnabled=true
RfKill:
 0: phy0: Wireless LAN
  Soft blocked: no
  Hard blocked: no
SourcePackage: network-manager
SystemImageInfo: Error: [Errno 2] No such file or directory: 'system-image-cli'
UpgradeStatus: Upgraded to saucy on 2013-08-09 (54 days ago)
nmcli-con:
 NAME UUID TYPE TIMESTAMP TIMESTAMP-REAL AUTOCONNECT READONLY DBUS-PATH
 Wired connection 1 99a6c07f-9a94-4c8e-82dd-0381befd6f90 802-3-ethernet 1380753272 Wed 02 Oct 2013 05:34:32 PM CDT yes no /org/freedesktop/NetworkManager/Settings/1
 9739 172c6f5c-b69c-40dd-ac1b-a279c84a17f8 802-11-wireless 1380763079 Wed 02 Oct 2013 08:17:59 PM CDT yes no /org/freedesktop/NetworkManager/Settings/0
nmcli-dev:
 DEVICE TYPE STATE DBUS-PATH
 eth0 802-3-ethernet unavailable /org/freedesktop/NetworkManager/Devices/1
 wlan0 802-11-wireless connected /org/freedesktop/NetworkManager/Devices/0
nmcli-nm:
 RUNNING VERSION STATE NET-ENABLED WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
 running 0.9.8.0 connected enabled enabled enabled enabled enabled

Revision history for this message
Ian Nicholson (imnichol) wrote :
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed
Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

Confirmed. It does happen occasionally.

Changed in network-manager (Ubuntu):
importance: Undecided → Medium
tags: added: rls-s-incoming
Revision history for this message
Ian Nicholson (imnichol) wrote :

I've edited the title of the bug to reflect that this occurrs for wired networks as well. My fix still works for that case as well.

summary: - Wireless network does not come up after resuming from suspend.
+ Network does not come up after resuming from suspend.
Martin Pitt (pitti)
Changed in systemd (Ubuntu):
status: New → Invalid
Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

Are you able to suspend again after resuming your system? I was not able to do so ("Operation already in Progress").

Revision history for this message
Ian Nicholson (imnichol) wrote : Re: [Bug 1234469] Re: Network does not come up after resuming from suspend.

On 10/07/2013 05:59 PM, Thaddäus Tintenfisch wrote:
> Are you able to suspend again after resuming your system? I was not able
> to do so ("Operation already in Progress").
>
Yes, although I didn't try to bring the network up between the two times
that I suspended it.

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

I assume that my issue is related to logind being not able to inform upower about the state change (sleep -> awake). As a result network-manager does not update its state automatically, because it relies on upower.

Revision history for this message
Martin Pitt (pitti) wrote :

Thaddaeus, that would sound like bug 1196752, but that was supposed to be fixed in upower already. Does

  dbus-send --print-reply --system --dest=org.freedesktop.UPower /org/freedesktop/UPower org.freedesktop.UPower.Suspend

work more than once for you? (See description of that bug for details)

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

Yes, it does work all the time. However, suspending via logind does not work anymore:

$ dbus-send --print-reply --system --dest=org.freedesktop.login1 /org/freedesktop/login1 org.freedesktop.login1.Manager.Suspend boolean:true
Error org.freedesktop.DBus.Error.Failed: Operation already in progress

This issue does not occur on every suspend/resume cycle, it happens occasionally.

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

There is also bug 1184262, which is addressing the same issue (in my case).

Martin Pitt (pitti)
Changed in systemd (Ubuntu):
status: Invalid → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
Revision history for this message
Julien Olivier (julo) wrote :

Maybe a hint:

pm-utils (1.4.1-9git1) raring; urgency=low

  Upload current Debian packaging git head.

  * debian/rules: Stop installing sleep.d/55NetworkManager. Current
    NetworkManager does not even expose this API any more, so the
    sleep()/wake() calls just always fail. As NM is apparently able to deal
    with suspends just fine, no need to waste cycles on this.

Revision history for this message
Thaddaeus Tintenfisch (thad-fisch-deactivatedaccount) wrote :

So it happened again, but on a different machine. After waking it up from hibernation the network-manager remained in the "asleep" state and logind reported that it is still in "PrepareForSleep" mode.
I am not sure, if restoring the pm-utils hook will resolve the actual issue.

Revision history for this message
Tom Cameron (drdabbles) wrote :

that: That error indicates the issue happened during suspend/hibernate. NetworkManager never completed or reported completion of the sleep task it was sent. Could be why it never got woken up.

Revision history for this message
Martin Pitt (pitti) wrote :

Thaddäus Tintenfisch [2013-10-14 23:09 -0000]:
> I am not sure, if restoring the pm-utils hook will resolve the
> actual issue.

That tries to call org.freedesktop.NetworkManager.sleep() and .wake(),
these methods don't even exist. There is a Sleep(boolean) method
though, which looks like a replacement. But NM should already listen
to logind for those (--with-suspend-resume=systemd).

Revision history for this message
Julien Olivier (julo) wrote :

That kind of bugs should really prevent a distribution from being released... I know it's not Debian, but I didn't think the quality standard was *that* low.

Revision history for this message
Anders Aagaard (aagaande) wrote :

Suspend not working seems like a release blocker to me too..

Revision history for this message
Catalin Hritcu (catalin-hritcu) wrote :

Updated to 13.10 just to run into this bug. It happens to me every time I close the lid (Suspend). Every single Ubuntu update has been a similar fiasco for me. I'm beyond disapointed.

Revision history for this message
Tom Cameron (drdabbles) wrote :

How was this not a blocker for release? We're talking about impacting every single Ubuntu user that suspends their computer, and the entire goal of Ubuntu is to make Linux easier for the average user! I happen to be knowledgeable enough to know NM has a power state within itself that I can set. My family, however, would never even know to look for this.

Revision history for this message
KoRnKloWn (kornklown) wrote :
Revision history for this message
Ian Nicholson (imnichol) wrote :

On 10/20/2013 01:47 PM, Dr. Dabbles wrote:
> How was this not a blocker for release? We're talking about impacting
> every single Ubuntu user that suspends their computer, and the entire
> goal of Ubuntu is to make Linux easier for the average user! I happen to
> be knowledgeable enough to know NM has a power state within itself that
> I can set. My family, however, would never even know to look for this.
>
Does if affect everyone? I was under the impression that it didn't.

Revision history for this message
Pablo180 (paultait22) wrote :

Well I wouldn't say it was a release blocker not being able to suspend, you can always hibernate, I mean it's not like they've also removed hibernate right? Oh wait!

Revision history for this message
Martin Pitt (pitti) wrote :

Dr. Dabbles [2013-10-20 18:47 -0000]:
> How was this not a blocker for release? We're talking about impacting
> every single Ubuntu user that suspends their computer, and the entire
> goal of Ubuntu is to make Linux easier for the average user!

Most certainly not. I haven't heard any complaints about this on
recent conferences where we had dozens of people in the same room
running saucy and suspending all the time, and I never saw that happen
either. Of course I do believe you that this is broken under some
conditions, but it hasn't been fixed yet precisely most people do not
have this, and thus it's not easily reproduced.

That said, if someone can reproduce this problem, it might be helpful
to do

$ sudo -i
# stop systemd-logind
# killall systemd-logind; /lib/systemd/systemd-logind

which starts logind in the foreground; then suspend/resume, try to
suspend again, and copy&paste the whole output. Hopefully there's some
error message which sheds some light on this.

Revision history for this message
Ian Nicholson (imnichol) wrote :

On 10/20/2013 03:27 PM, Martin Pitt wrote:
> Most certainly not. I haven't heard any complaints about this on
> recent conferences where we had dozens of people in the same room
> running saucy and suspending all the time, and I never saw that happen
> either. Of course I do believe you that this is broken under some
> conditions, but it hasn't been fixed yet precisely most people do not
> have this, and thus it's not easily reproduced. That said, if someone
> can reproduce this problem, it might be helpful to do$ sudo -i # stop
> systemd-logind # killall systemd-logind; /lib/systemd/systemd-logind
> which starts logind in the foreground; then suspend/resume, try to
> suspend again, and copy&paste the whole output. Hopefully there's some
> error message which sheds some light on this.
I tried your

Revision history for this message
Ian Nicholson (imnichol) wrote :

On 10/20/2013 03:27 PM, Martin Pitt wrote:
> *** This bug is a duplicate of bug 1184262 ***
> https://bugs.launchpad.net/bugs/1184262
>
> Dr. Dabbles [2013-10-20 18:47 -0000]:
>> How was this not a blocker for release? We're talking about impacting
>> every single Ubuntu user that suspends their computer, and the entire
>> goal of Ubuntu is to make Linux easier for the average user!
> Most certainly not. I haven't heard any complaints about this on
> recent conferences where we had dozens of people in the same room
> running saucy and suspending all the time, and I never saw that happen
> either. Of course I do believe you that this is broken under some
> conditions, but it hasn't been fixed yet precisely most people do not
> have this, and thus it's not easily reproduced.
>
> That said, if someone can reproduce this problem, it might be helpful
> to do
>
> $ sudo -i
> # stop systemd-logind
> # killall systemd-logind; /lib/systemd/systemd-logind
>
> which starts logind in the foreground; then suspend/resume, try to
> suspend again, and copy&paste the whole output. Hopefully there's some
> error message which sheds some light on this.
>
Sorry about that previous message, accidentally hit "send".
I am unable to get any information through the suggested troubleshooting
steps. I can replicate it 100% on my hardware though. Would the
contents of /var/log/syslog be helpful?

Revision history for this message
robdanet (mailatony) wrote :

I resolved the problem by editing the keyfile plugin /etc/NetworkManager/NetworkManager.conf by appending
[connection]
id=Auto eth0
uuid=<-----------------------your connection uuidd, find it with the command $ nmcli -p c list
type=802-3-ethernet
autoconnect=true
timestamp=0

[ipv4]
method=auto

[802-3-ethernet]
mac-address=<---------your router mac address

Revision history for this message
Martin Pitt (pitti) wrote :

Ian Nicholson [2013-10-20 20:51 -0000]:
> Sorry about that previous message, accidentally hit "send".
> I am unable to get any information through the suggested troubleshooting
> steps. I can replicate it 100% on my hardware though. Would the
> contents of /var/log/syslog be helpful?

Could be, although it is most likely not sufficient; attach it after a
suspend/resume failure, please?

Thanks!

Revision history for this message
Catalin Hritcu (catalin-hritcu) wrote :

I've tried suggested by pitti. After the first suspend and resume I get this:
Lid closed.
Suspending...
Failed to send delayed message: Message did not receive a reply (timeout by message bus)
Lid opened.

Networking was disabled so I brought it back up with "nmcli nm sleep false". Then I suspended again. After the second suspend trying to resume just led to another suspend I didn't ask for. Had to force another resume (power button) before the thing actually resumed:

Lid closed.
Suspending...
Failed to execute operation: Message did not receive a reply (timeout by message bus)
Suspending...
Operation finished.
Lid opened.

Earlier today it happened to me that I couldn't resume at all because of this problem happening many times in a row. I would get to the login prompt but the machine would go back to sleep so fast that I wouldn't even have time to enter my password. I had to power off and restart the machine to take it out of that state. I'm on a Dell Latitude E6400.

BTW. Should I stop commenting here and switch to #1184262 instead?

Revision history for this message
robdanet (mailatony) wrote :

Unfortunately the previous modification doesn't works anymore. Anyway I noticed a comma in the file /etc/NetworkManager/NetworkManager.conf.dpkg-old :

[main]
plugins=ifupdown,keyfile

no-auto-default=00:xx:xx:xx:xx:xx , <-----(?)

[ifupdown]
managed=false
I removed it and now everyting seems to be fine. Fingers crossed.

Revision history for this message
Catalin Hritcu (catalin-hritcu) wrote :

Here is one more log 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.

Revision history for this message
Alex P (alexander-e-popov) wrote :

I experience the same problem occasionally, but with my wired connection. Running "nmcli nm sleep false" helps to solve the problem.

Revision history for this message
Jean-Marc (m-balthazar) wrote :
penalvch (penalvch)
no longer affects: systemd (Ubuntu)
affects: network-manager (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
Revision history for this message
Vladimir (vladimir-l) wrote :

Hi,

I'm experiencing the same issue, very easy to reproduce: go to "Suspend" mode two times, after second wake up the network manager claims to be disconnected. Additionally "Suspend", "Restart", and "Shutdown" commands from menu do not work, however "sudo reboot" and "sudo poweroff" from terminal works w/o a problem.

I'm using wired connection on my desktop PC and didnt have any issues with suspend using Ubuntu 13.04

This bug is really annoying, and I hope it will get resolved soon. I'm ready to help with troubleshooting this issue!

Regards,
vladimir

Revision history for this message
Catalin Hritcu (catalin-hritcu) wrote :

@Vladimir: you're commenting on a duplicate. There is already a potential fix in the comments of #1184262.

Revision history for this message
Vladimir (vladimir-l) wrote :

@Catalin: thank you very much! the solution mentioned in the bug #1184262 has really helped me

Revision history for this message
C de-Avillez (hggdh2) wrote :

@all: if you change the status of a bug, or mark/unmark it as a duplicate, please *explain*, in a comment, why you are doing it. Certainly, if you think this is a wrong duplicate, you have some reasoning that may help us understand what happened.

Revision history for this message
robdanet (mailatony) wrote :

Personally I don't think that this is coming from the kernel, because I reproduced it with older kernels. If this had been the case the bug would show up before upgrading to 13.10.
About the bug, I'm experiencing exactly the same thing as Vladimir. I can add that for me the workaround works for not more than two times, after that, on resuming from sleep, the network-manager remains in sleep state, and the restart/shutdown functionalities are gone.

Revision history for this message
Launchpad Janitor (janitor) wrote :

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

Changed in systemd-shim (Ubuntu):
status: New → Confirmed
penalvch (penalvch)
affects: systemd (Ubuntu) → systemd-shim (Ubuntu)
Changed in systemd-shim (Ubuntu):
status: New → Incomplete
Revision history for this message
penalvch (penalvch) wrote :

robdanet, it would be best if you filed your own report as the systemd-shim issue has demonstrated hardware dependency. You may do this via a terminal:
ubuntu-bug systemd-shim

Revision history for this message
Ian Nicholson (imnichol) wrote :

On 11/18/2013 06:06 PM, Christopher M. Penalver wrote:
> Ian Nicholson, could you please provide the information noted in
> https://wiki.ubuntu.com/DebuggingDBus ?
>
> ** Package changed: systemd (Ubuntu) => systemd-shim (Ubuntu)
>
> ** Changed in: systemd-shim (Ubuntu)
> Status: New => Incomplete
>
There isn't a lot of information on that page. What exactly do you want
me to do?

Revision history for this message
Ian Nicholson (imnichol) wrote :

On 11/18/2013 07:20 PM, Christopher M. Penalver wrote:
> Ian Nicholson, provide a Dbus log during suspend-resume.
>
I actually don't think that this is a bug that's affecting me. The
resolution for bug 1184262 resolved it for me. Sorry!

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

Other bug subscribers

Remote bug watches

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