Network does not come up after resuming from suspend.

Bug #1234469 reported by Ian Nicholson on 2013-10-03
520
This bug affects 112 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Medium
Unassigned
systemd-shim (Ubuntu)
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

Ian Nicholson (imnichol) wrote :
Launchpad Janitor (janitor) wrote :

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

Changed in network-manager (Ubuntu):
status: New → Confirmed

Confirmed. It does happen occasionally.

Adolfo Jayme (fitojb) on 2013-10-04
Changed in network-manager (Ubuntu):
importance: Undecided → Medium
tags: added: rls-s-incoming
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) on 2013-10-07
Changed in systemd (Ubuntu):
status: New → Invalid

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

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.

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.

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)

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.

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

Martin Pitt (pitti) on 2013-10-14
Changed in systemd (Ubuntu):
status: Invalid → New
Launchpad Janitor (janitor) wrote :

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

Changed in systemd (Ubuntu):
status: New → Confirmed
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.

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.

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.

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).

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.

Anders Aagaard (aagaande) wrote :

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

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.

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.

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.

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!

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.

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

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?

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

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!

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?

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.

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.

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.

Jean-Marc (m-balthazar) wrote :
no longer affects: systemd (Ubuntu)
affects: network-manager (Ubuntu) → linux (Ubuntu)
Changed in linux (Ubuntu):
status: Confirmed → Incomplete
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

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

Vladimir (vladimir-l) wrote :

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

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.

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.

Launchpad Janitor (janitor) wrote :

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

Changed in systemd-shim (Ubuntu):
status: New → Confirmed
affects: systemd (Ubuntu) → systemd-shim (Ubuntu)
Changed in systemd-shim (Ubuntu):
status: New → Incomplete

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

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?

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  Edit
Everyone can see this information.

Other bug subscribers