Regression potential: Low. Flushing the session bus was introduced in version 4 and is obviously bogus as in a system D-BUS service there is no session bus. This causes lots of confusing error messages and unnecessary overhead like trying to start dbus-launch. Flushing the system bus is low-risk, in most cases it's a no-op and it would otherwise prevent losing signals after waking up. No known regressions.

TEST CASE: Run several suspend/resume cycles with the lid, session indicator menu, and verify that the network comes back up. It is known that this fix is necessary but not sufficient, so it is not expected to fix all cases. But it should not make things worse, so if network now does not come up any more on a machine where it previously worked this would count as failure/regression.

Gabriel Devenyi, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available (not the daily folder) following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue.Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.12

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

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.

In the other bug report, I said that "sudo pm-suspend" didn't work, which is wrong. Maybe I forgot to re-activate the network after some previous test ...

So my current results are (tested >5 times):
All of these methods:
- closing the lid
- using the Unity menu -> "Suspend"
- sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
show the following behaviour:
The screen turns off immediately, however it takes >20s until the laptop finally suspends. During these 20s, I can reactivate the screen by moving the mouse or pressing a key and then even login and do some stuff - until the 20s are over and the laptop goes off. When turning it on again, the network does not work - and if I logged in before it went off, I don't need to login after resume.

"sudo pm-suspend" on the other hand always works: It always suspends immediately and on resume, the network is as it was before. But I don't need to login in this case.

Also, I noticed that I get two types of login screens (seemingly randomly):
- One has a Gnome3-like, black top bar on the login screen (I use the normal Unity-design that would have a gray bar there) and the login window is in German (my system locale).
- Sometimes, the top bar is missing, so there is only my wallpaper and the login window. In these cases, the login screen is in English. This is the type of login screen I get, when I click "Lock" in the Unity menu or press Ctrl+Alt+L.
Both login screens are entirely different from what I get on normal startup (which is one with gray background, Gnome3-top bar with no own background).

Sometimes, the screen is initially black after resume (except for the labels on the top bar) and I have to press a key to see the login window and the wallpaper.

And very rarely I get a very weird behavior after resume: The system logs me out randomly (after 1-5 seconds) and I have to re-login.

The login screen issues are probably not related to this bug report. I deactivated "Require my password when waking from suspend" and the network-problem is still there.

I just modified /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service in the way you asked. Then I suspended using the Unity menu. However, the laptop never turned off (usually it does after 20-30s) - at least not for over a minute. So I pressed I key and was able to login (and post this). However, the network was already gone (without suspend!). The reason is in the log file:
env: annotate-output: No such file or directory

So I ran "sudo apt-get install devscripts" and retried. See the logfiles attached.

Hey Martin, I tried the command you gave in comment #6, and I could reproduce the network problem in 13 tries. Unfortunately this seems to invalidate your hypothesis on only the lid closing causing the problem.

but not what kind of error unfortunately. At the moment I don't have an idea what happens there, I'll discuss with Ryan and try to get something like that by sprinkling some sleeps around pm-utils and the code.

Rafael and Gabriel's pm-suspend.log shows no oddities, and suspend looks fairly fast. Philipp's pm-suspend log confirms that the suspend takes some 30 seconds for him, which is absurdly long. That's yet another bug (might be in pm-utils or in the kernel); Philipp, can you please report it against pm-utils, and we debug it in another bug report?

Looks like I come from bug #1184262, and I'm experiencing the same problem :-) pm-suspend works always, quickly and the network is available without problems, however if I suspend the laptop with the lid or Unity menu, network never comes back. I'll try to send you a log, so you can review it here too.

Daniel Lombraña González [2013-11-21 7:33 -0000]:
> Looks like I come from bug #1184262, and I'm experiencing the same
> problem :-) pm-suspend works always, quickly and the network is
> available without problems, however if I suspend the laptop with the lid
> or Unity menu, network never comes back.

How long does it take from the action (lid close/menu click) to when
the laptop is actually suspended (i. e. it powers down and the suspend
indicator light switches on)?

> I'll try to send you a log, so you can review it here too.

No need to waste your time generating more logs. The symptoms sound
exactly like the others in this report, so I first need to get an idea
how to debug the AWOL D-BUS connection.

Please upgrade to my systemd-shim package in https://launchpad.net/~pitti/+archive/sru-test (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.

Thanks Gabriel. That confirms that the D-BUS mess is fixed, and it also times out properly 10 seconds after the suspend call. Both logs now look spotless. So I'm afraid I need to ask you to get a complete system D-BUS log of the whole suspend process, to check what happens to the PrepareForSleep signal. You already mastered that in comment 2, can you please re-do it with this fixed shim version? Thanks!

Thanks but unfortunately it didn't work for me either. I have just resumed after about a 5 hour hibernation only to have no networking once again. I have installed the updated systemd-shim from the PPA but I haven't restarted since installing, not sure whether that makes a difference? I'll try again tomorrow after a reboot.

Gabriel, indeed the "PrepareForSleep false" signal is still missing. I now have run out of ideas why that would be, as the communication between shim and logind seems fine. Also, I cannot reproduce this at all with adding sleeps to places. This needs to be studied in more detail to get more ideas where to continue with debugging.

Pablo, reboot shouldn't make a difference, but hibernation does. We disable hibernate by default in Ubuntu, and the mechanics of that are quite a bit different. Can you please file a separate bug about that? Let's keep this bug focused on resuming from suspend, it's hard/complex enough as it is :-( Thanks!

Interesting: I had this bug with a 13.04 -> 13.10 upgrade. I did not have it on a fresh 13.10 install. However, at some point after installing a few packages, it came back (very reproducibly), combined with the 'infinite suspend loop' problem that has also been reported, and also many of the symptoms reported by Philipp Keck.

I again reinstalled fresh, and again things seem to be fine. Unfortunately I didn't keep a list of which packages I installed. However, I did install some packages related to power management, and I'm guessing one of them is the culprit:

tlp
tlp-rdw
tp-smapi-dkms
acpi-call-tools

Just uninstalling them did not fix the problem though.

Maybe other people having the problem could try running from the LiveCD and see if that makes a difference?

For me the PPA does not work but I do NOT use TLP. However, I do use "Jupiter" http://wiki.ubuntuusers.de/Jupiter which is supposed to increase battery life (and actually does that pretty well). Also I used powertop once to "fix" all the items it offered.

I'm on Utopic development version (i. e. 14.10) and there is no way to get network back on automatically after hibernate! (suspend often caused my machine to hard-lock so I can only use hibernate in my case)

It's a shame everyone ignores us, saying this is of minor importance. BTW, it worked fine in Saucy, so this is evidence enough that someone dabbled with the code and broke it AGAIN.

Yes, hibernation itself DOES work in Utopic (Lubuntu flavor). However, as I notice that I'm even able to hibernate my machine via GUI menu, I might have done some change that enables this (because I do remember there was something on launchpad about this being disabled in the vanilla installation)

But anyways, 'sudo pm-hibernate' works fine regardless of what policy has been set.

However, I've enabled 'S3' mode in my BIOS, though I have no idea whether 'Buntu will care about that at all. :)

Also experiencing this on Ubuntu 14.04. It's much easier to reproduce the longer you leave the computer in hibernation. I usually can't reproduce if I hibernate for a few minutes and then resume, but if I hibernate overnight and resume the next morning, this bug almost always occurs. Doing a sudo service network-manager restart works around it, but is annoying.

For what it's worth, I added the command "pkill -f wpa_supplicant" after "nmcli nm sleep false" in my /etc/pm/sleep.d/ thaw or resume script, based on another similar bug that was reported elsewhere (I've lost the link; sorry).

Now the wireless interface comes back up pretty consistently after a return from suspend... however, from time to time, after coming back from suspend once, it returns to suspend a few seconds later. It's never done this repeatedly after an initial suspend.

Not sure if this amounts to forward progress or just sideways wiggling, but I thought I'd report it in case it rang any bells...

@David or anyone else having this problem, I too didn't have any luck with "nmcli nm sleep false" in my script under /etc/pm/sleep.d/ either but when I used "service network-manager restart" instead it worked flawlessly. I have not had any problems for almost five months and it doesn't cause any side effects.

!!! I have just booted from live Linux Mint xfce edition - everything is OK with network there. Also I booted from Xubuntu and this bug appears there. Is there anyone with Linux Mint with the same bug?

Confirming: I installed Xubuntu Utopic 2 days ago, and this bug is also biting me. However, I noticed that it depends on the time interval between suspend and resume: the bug only happens when I resume 2+ hours after I suspend (it always happens in the morning when I first open the laptop lid).

Why is this bug still unassigned more than a year later? Isn't the use of suspend + network-manager sufficiently common? It seems to me that this is a critical bug and I am quite shocked that no developer has deigned so much as to look at it in more than a year. I can do "sudo restart network-manager" every time I come back from suspend. But how many of among the non-technical masses that Ubuntu targets would know how to start the terminal application? This is quite ridiculous.

> @r0lf this is still happening in 14.10/Utopic should it be reopened
> there?
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1252121
>
> Title:
> missing PrepareForSleep signal after resuming, causing networking to
> stay disabled
>
> Status in NetworkManager:
> New
> Status in wicd:
> New
> Status in systemd-shim package in Ubuntu:
> Confirmed
> Status in systemd-shim source package in Saucy:
> Won't Fix
> Status in systemd-shim source package in Trusty:
> Confirmed
>
> Bug description:
> As per request from bug #1184262, this is a new report, along with
> dbus (to be attached)
>
> ProblemType: Bug
> DistroRelease: Ubuntu 13.10
> Package: systemd-services 204-0ubuntu19
> Uname: Linux 3.12.0-custom x86_64
> ApportVersion: 2.12.5-0ubuntu2.1
> Architecture: amd64
> Date: Sun Nov 17 20:24:41 2013
> MarkForUpload: True
> SourcePackage: systemd
> UpgradeStatus: Upgraded to saucy on 2013-10-17 (31 days ago)
>
> SRU INFORMATION:
> FIX: https://github.com/desrt/systemd-shim/commit/9e1ebe3ab (in trusty
> already)
>
> Regression potential: Low. Flushing the session bus was introduced in
> version 4 and is obviously bogus as in a system D-BUS service there is
> no session bus. This causes lots of confusing error messages and
> unnecessary overhead like trying to start dbus-launch. Flushing the
> system bus is low-risk, in most cases it's a no-op and it would
> otherwise prevent losing signals after waking up. No known
> regressions.
>
> TEST CASE: Run several suspend/resume cycles with the lid, session
> indicator menu, and verify that the network comes back up. It is known
> that this fix is necessary but not sufficient, so it is not expected
> to fix all cases. But it should not make things worse, so if network
> now does not come up any more on a machine where it previously worked
> this would count as failure/regression.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/network-manager/+bug/1252121/+subscriptions
>

The issue of the network not reconnecting after a suspend cycle is present also in 14.10 (utopic).

Maybe it is another bug, but if this is the case, the fact that other bugs opened on the issue are made duplicate of this should be corrected.

The issue completely breaks the possibility of using wake on lan.

Machine is suspended
Machine is waken on lan
Machine is unusable because it properly wake on lan, but it is not on the lan.

Please consider providing a script in /etc/pm/sleep.d/ as a solution as a SRU until a better solution can be found since having the network not connecting on machines that do not have a human operator in front of them means compelling the operator to taking a trip to the machine and long down times.

Hello guys! The bug seems to be fixed on my PC. There were lots of changes since the last check, but the last I did was disabling ACPI HPET Table in BIOS. Also I got rid of indicators.
Other BIOS settings:

After an upgrade to 14.10 the workaround stopped working (restarting network manager each resume). Due to another problem I had to reinstall 14.10 and the problem is no longer present for me after the reinstall. I am not sure whether this has been fixed in 14.10 or whether it was the re-installation that fixed it, but either way the problem has been fixed for me.

Spoke too soon, just hibernated and then resumed with Ethernet cable plugged in and the problem occurred. Killing or restarting Network Manager just caused nm-applet to crash so I had to restart that - which is probably why the workaround no longer works.

I haven't noticed this problem in the week or so since the reinstall, although I have been using wifi and not ethernet all that time - my wifi was disabled via Network Manager before hibernating this time., so that may be related.

Have anybody tried to remove light-locker? Maybe light-locker causes it? Or lightdm... As for me the bug isn't reproducable currently. Also I have upgraded to 3.16 kernel and suspending is much faster now

Any progress on this issue? I experience all of the symptoms posted by #8, are more logs required to properly troubleshoot this issue?

The proposed workaround for enabling the network using "nmcli nm sleep false" works ok for me, but I also use VirtualBox quite heavily and any running machines refuses to resume due to the missing "PrepareForSleep false" signal. I can see in the VirtualBox source-code that it waits for this signal to determine if the host has properly resumed from standby in order to resume all the guests from a "Paused" state.

Are there any way to also "fake" the sending this dbus-signal via a sleep.d-script to make VirtualBox happy as a workaround for this issue?