missing PrepareForSleep signal after resuming, causing networking to stay disabled

Dbus log during suspend-resume as per https://wiki.ubuntu.com/DebuggingDBus

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.

The "PrepareForSleep false" signal is missing. Invalidating kernel task to stop the kernel bug auto-responder from nagging (please ignore the previous comment).

Can you please modify ("sudo gedit", for example) /usr/share/dbus-1/system-services/org.freedesktop.systemd1.service to set the Exec= line to

Exec=/bin/sh -c 'env G_DBUS_DEBUG=all annotate-output /usr/lib/x86_64-linux-gnu/systemd-shim >> /tmp/systemd-shim.log 2>&1'

Then please do a suspend/resume cycle, and attach /tmp/systemd-shim.log here. Please also attach /var/log/pm-suspend.log.

Thanks!

In bug 1184262, Catalin made an interesting observation that this failure seems to only happen for her when using the lid to suspend, but not when using the session menu or power button.

It would 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.

Martin, adding the Exec line as requested results in failure of the suspend portion of suspend-resume, so I cannot provide a log

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.

pm-suspend.log after unsuccessful suspend-resume-cycle (i.e. network didn't work afterwards).

Philipp, Gabriel: I'm sorry, I didn't consider that annotate-output isn't installed by default. It's in the "devscripts" package. Please install it with "sudo apt-get install --no-install-recommends devscripts". (It's useful to add timestamps to the log output).

I used the command in #6 and the system suspended normally. Upon resuming the system the network was still diabled and I had to kill the networkmanger to wake it up.
I attached the pm-suspend.log

Followed the instructions in #5.

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.

Suspend-resume cycle, network disabled on resume.

Suspend-resume cycle pm-suspend.log

Thanks Rafael, Gabriel, Philipp! Your logs agree in the fact that at the time it tries to call, or called pm-suspend, the shim's D-BUS connection goes away:

09:20:16 E: (process:3100): GLib-GIO-CRITICAL **: g_dbus_connection_flush_sync: assertion 'G_IS_DBUS_CONNECTION (connection)' failed

(and some noise around it). Rafael's log additionally shows

  15:05:35 E: ** (process:19670): WARNING **: Error while running '/usr/sbin/pm-suspend'

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?

So let's use this bug report for the broken D-BUS connection.

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.

Hello Daniel,

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.

Thanks!

I can reproduce this. I added a "sleep 5" to a pm-utils sleep.5 script. When I run systemd-shim in the foreground in my session, I get this output after resuming:

14:39:18 O: GDBus-debug:Address: In g_dbus_address_get_for_bus_sync() for bus type 'session'
14:39:18 O: GDBus-debug:Address: env var DBUS_SESSION_BUS_ADDRESS is not set
14:39:18 O: GDBus-debug:Address: env var DBUS_SYSTEM_BUS_ADDRESS is not set
14:39:18 O: GDBus-debug:Address: env var DBUS_STARTER_BUS_TYPE is not set
14:39:18 O: GDBus-debug:Address: Running 'dbus-launch --autolaunch=daca3d32fc003f5e41857948525b8e7d --binary-syntax --close-stderr' to get bus address (possibly autolaunching)
[...]
14:39:18 O: GDBus-debug:Address: dbus-launch stderr output:
14:39:18 O: 5994: Autolaunch enabled (using X11).
14:39:18 O: 5994: --exit-with-session automatically enabled
14:39:18 O: 5994: Connected to X11 display ':0.0'
14:39:18 O: 5994: dbus-daemon is already running. Returning existing parameters.
14:39:18 O: 5994: dbus-launch exiting
14:39:18 O: GDBus-debug:Address: Returning address 'unix:abstract=/tmp/dbus-MIO6Nrok3P,guid=7a808dc6cc702b9d36d2fc23528f5e40' for bus type 'session'
14:39:18 O: GDBus-debug:Auth: CLIENT: initiating
14:39:18 O: GDBus-debug:Auth: CLIENT: sent credentials 'GCredentials:linux-ucred:pid=5062,uid=0,gid=0'
14:39:18 O: GDBus-debug:Auth: CLIENT: writing 'AUTH\r\n'
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForReject
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForReject, read 'REJECTED EXTERNAL DBUS_COOKIE_SHA1 ANONYMOUS'
14:39:18 O: GDBus-debug:Auth: CLIENT: Trying to choose mechanism
14:39:18 O: GDBus-debug:Auth: CLIENT: Trying mechanism 'EXTERNAL'
14:39:18 O: GDBus-debug:Auth: CLIENT: writing 'AUTH EXTERNAL 30\r\n'
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForOK
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForOK, read 'OK 7a808dc6cc702b9d36d2fc23528f5e40'
14:39:18 O: GDBus-debug:Auth: CLIENT: writing 'NEGOTIATE_UNIX_FD\r\n'
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForAgreeUnixFD
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForAgreeUnixFD, read='AGREE_UNIX_FD'
14:39:18 O: GDBus-debug:Auth: CLIENT: writing 'BEGIN\r\n'
14:39:18 O: GDBus-debug:Auth: CLIENT: Done, authenticated=1

and indeed I see a new dbus daemon:

root 4610 0.0 0.0 24444 624 pts/15 S 14:38 0:00 dbus-launch --autolaunch=daca3d32fc003f5e41857948525b8e7d --binary-syntax --close-stderr
root 4613 0.0 0.0 30384 968 ? Ss 14:38 0:00 //bin/dbus-daemon --fork --print-pid 5 --print-address 7 --session

If I run the shim under env -u DISPLAY (as it would when being D-BUS activated), I get the same D-BUS errors as in the logs of the reporters.

Argh, now that I'm looking for what is using the session bus: Look at the original attempt to flush the bus and spot the error: https://github.com/desrt/systemd-shim/commit/136ed11430

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.

I'll land this upstream and upload an SRU next Monday.

Unfortunately, this doesn't seem to have fixed it, suspend-resume via the laptop function keys still disabled networking.

Gabriel, can you please create a new systemd-shim log just like in comment 5?

systemd-shim log with 5-0ubuntu0.0pitti1

pm-suspend log of 5-0ubuntu0.0pitti1

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!

dbus-log with 5-0ubuntu0.0pitti1

Martin,

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!

Does anyone else have more luck with the current PPA version?

Thanks for the fix package, which worked for me.

> Pablo, reboot shouldn't make a difference

Sorry, I'm wrong about that. After installing the update you need to at least kill logind; it's safest to just reboot indeed.

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?

That is a very interesting observation, I also use TLP to control my battery/AC transition of settings.

I can't test with a LiveCD due to there being a no-display kernel bug with some intel cards and that kernel version though...

Neil, I also have TLP and tlp-rdw installed, but none of the others, so it looks like you may be right. I will download the LiveCD and try with that.

There is no "tlp" package in Ubuntu, also not in earlier releases. What does that do?

http://linrunner.de/en/tlp/tlp.html

Essentially, it's a highly configurable battery/AC profile manager.

So is everyone for whom the PPA package still does not work using TLP then?

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 not using TLP or Jupiter or powertop, still I have the problem even with the PPA.

I'm using TLP and the bug is still here with 5-0ubuntu0.0pitti1

>> I'm not using TLP or Jupiter or powertop, still I have the problem even with the PPA.

Same for me. Problem seems fixed on my desktop PC but still happens intermittently on my netbook.

Thanks. So let's use a new bug report for the TLP case. I now need a D-BUS system and systemd-shim log from someone who can reproduce this problem without Jupiter/TLP. Please see comment 5 and https://wiki.ubuntu.com/DebuggingDBus . Thanks!

I'm here on Pitti's advice from bug #1251054 -- my networking wouldn't come back from a suspend, then finally I couldn't invoke suspend from the gear-menu or by closing my laptop lid, but pm-suspend worked.

I've been running systemd-shim version 5-0ubuntu0.0pitti1 for several days on 13.10 without either problem.

The previous problems were not 100% reliable (details are complicated and probably uninteresting), but I'd have expected to see one or the other at least once by now. When the SRU details are filled in I'll be happy to verification-done this bug if the problem hasn't recurred by then.

I also still have this issue. I can also add, that when this happens, shutdown doesn't work and I need to switch to command line to be able to reboot a computer.

I still have the bug with TLP disabled.

New crazy thing I just experienced!

I woke the system from suspend (which I had suspended from the key combination), 20-30 seconds later, the screensaver did it's lock thing (while I was using the machine, it wasn't idle), I hit a key, it lit up and I typed in my password, 30 seconds later again, it did it again.

When I unlock it again... NetworkManager miraculously woke up and connect to wifi!

I had not noticed this previously because it took so long and I would usually have killed NetworkManager first..

I need to try and get a log from this odd behaviour..

I uploaded the "flush the right bus" fix into trusty, as I really want to fix this in saucy-updates as well. But I'll reopen afterwards as it still does not seem to be sufficient.

Seth: I uploaded an SRU for this (needs to be reviewed/acked by SRU team). the "session → system bus" fix is an obvious one and seems to help you, so I'd be grateful if you could verify this.

@others: I know this is necessary but not sufficient, so I'll reopen after this. I'm still waiting for a D-BUS debug log without TLP or other non-standard facilities where this bug happens. Thanks!

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

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

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

  * New upstream release:
    - Flush the right bus (system, not session), to address another case of
      "PrepareForSleep signal is missing" which breaks networking after
      resuming. (LP: #1252121)
 -- Martin Pitt <email address hidden> Tue, 10 Dec 2013 10:54:18 +0100

Hello Gabriel, 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/6-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!

I just barely upgraded to 13.10, noticed this bug, slapped the systemd-shim package on my system from the -proposed repository (Installed: 6-0ubuntu0.13.10). The bug is still present for me. Forgive my hesitance to read through all the comments here, but the package did not fix my issue, I still needed to manually restart the network-manager service.

As I said, please only mark this as verification-failed if this update makes things *worse*. It's known that this fix alone (well, it's the third one..) isn't sufficient to fix it for many people. Thanks for testing!

@Martin: Consider asking the launchpad devs to integrate an 'issue list' of some sort so that the constant need to close/open new bugs that pertain to the same issues can be kept sane. Back when I did lots of launchpad work it was infuriating having to have all subscribers move to new bugs because a little corner case was fixed - it was very confusing to those affected as well.

Further, I must add that this issue affects me on every suspend/resume, not intermittantly.

Looks like it wakes up faster but still have the same problem of the network not coming back from suspend.

Also, because I'm sure you guys are totally loving all of my messages, I'm experiencing the bizarre issues detailed in #49 in full. I've had my screen lock on me three times while trying to just get things in order.

Seth Arnold, are you able to verify this -proposed package? the PPA one seemed to help for you. As above, this is a "it does not regress" check, not a "it fully fixes the problem for everyone" test.

@pitti: does it make a difference, if you use suspend_hybrid vs suspend maybe?
I am using suspend_hybrid myself (via override in /etc/pm/config.d/00-use-suspend-hybrid:
    # Use suspend_hybrid instead of suspend always (requires patch in pm-utils 1.4.1-13)
    if [ "$METHOD" = "suspend" ]; then
      METHOD=suspend_hybrid
    fi)

It is rather hard to trigger, but given a longer time in suspend mode (~15 minutes appear to be not enough) and a WiFi network change appears to trigger it always.

Martin, thanks for providing the -proposed package. I have been running with systemd-shim 6-0ubuntu0.13.10 for four or five business days with multiple suspends and resumes each day and have not had a re-occurrence of either (a) failed to sleep (b) network-manager failed on resume.

Something that might be related to comment #60 by jhfhlkjlj (fdsuufijjejejejej), I did see a funny screen flash shortly after resuming this morning, but it had no consequences for me. I believe I saw these flashes several weeks ago, before trying the version of systemd-shim in your ppa, so I do not believe this is a regression in the -proposed package.

So I am marking this verification-done.

Thanks!

Daniel Hahler [2013-12-16 17:03 -0000]:
> @pitti: does it make a difference, if you use suspend_hybrid vs suspend maybe?
> I am using suspend_hybrid myself (via override in /etc/pm/config.d/00-use-suspend-hybrid:

Certainly possible. Hibernation is off by default, and I haven't
seen any logs which explicitly use hybrid suspend.

It happened on my system over night. Attaching logs.

Setting to Triaged, given my non-TLP logs above.

For what it's worth, it happened again when resuming this morning.

Daniel, the logs look fine; can you please add a corresponding system D-BUS debug log? (https://wiki.ubuntu.com/DebuggingDBus) I need to know if the "PrepareForSleep false" gets sent properly. Also, you are using hybrid suspend, which hasn't been tested at all. Can you check if this bug also happens for a standard suspend for you? I. e. does the hybrid part make a difference or not? Thanks!

(The remainder of this bug is far from triaged -- it's absolutely unclear what breaks on the machines that are still affected)

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

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

  * New upstream bug fix release:
    - Write a sendsigs.omit.d file to prevent upstart from killing us during
      shutdown. That's the other half of preventing suspends during shutdown.
      (LP: #1211514)
    - Flush the right bus (system, not session), to address another case of
      "PrepareForSleep signal is missing" which breaks networking after
      resuming. (helps some people in LP: #1252121)
 -- Martin Pitt <email address hidden> Tue, 10 Dec 2013 10:59:08 +0100

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.

As promised, reopening the saucy task as well, for the people who are still affected.

@pitti
Ok, I have setup the dbus monitor (any filter suggestions?), tee'ing to a logfile.

I have then suspended and resumed (after a minute maybe), and there's no PrepareForSleep=false in the log, only:

    signal sender=:1.3 -> dest=(null destination) serial=1076 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep
       boolean true

The network also did not came up after resuming.

Is it safe/wise to post the dbus-monitor log unfiltered puclicitly, or can I send it directly to you?

I will now disable hybrid suspend and report back.

With the normal suspend methd, PrepareForSleep=false showed up now (and the network came up again), (together with PrepareForSleep=true):

    signal sender=:1.3 -> dest=(null destination) serial=1094 path=/org/freedesktop/login1;
interface=org.freedesktop.login1.Manager; member=PrepareForSleep
       boolean false

However, it usually requires a suspend cycle over night to trigger this bug anyway - so I will report back tomorrow.
(I was rather surprised that it was triggered in my last attempt)

Where is the PrepareForSleep=false signal emitted and what is it supposed to do?
Is it something NetworkManager requires to wake up again?

Daniel Hahler [2013-12-19 13:11 -0000]:
> I have then suspended and resumed (after a minute maybe), and there's no
> PrepareForSleep=false in the log, only:
>
> signal sender=:1.3 -> dest=(null destination) serial=1076 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep
> boolean true

Thanks. So that's still the case even through the shim works as
intended. I don't have an off-hand idea where to go from here, I need
to study in detail how PrepareForSleep is handled in logind.

> Is it safe/wise to post the dbus-monitor log unfiltered puclicitly, or
> can I send it directly to you?

Should usually be harmless, but the above was the main piece of
information I wanted to get out of it. It would also have the logind
calls/signals which might be interesting, but I can't say without
looking.

Thanks!

Daniel Hahler [2013-12-19 13:24 -0000]:
> With the normal suspend methd, PrepareForSleep=false showed up now (and
> the network came up again), (together with PrepareForSleep=true):

Interesting. To the other affected people: are you using hybrid
suspend or the "simple" (RAM only) suspend?

> Where is the PrepareForSleep=false signal emitted

That comes from logind, which is the component which provides the
"Suspend()" API for the desktop. It should send "PrepareForSleep
true", then it will wait until apps which registered a suspend
inhibitor are done with their pre-suspend actions, then do the actual
suspend, and after resume send the "PrepareForSleep=false" signal so
that clients can do their post-suspend actions.

> Is it something NetworkManager requires to wake up again?

Exactly. NM shuts down the network on PrepareForSleep=false, and
searches for networks/re-connects on PrepareForSleep=true.

Martin, for me this occurs in standard suspend, hybrid suspend and also hibernate.

Since using non-hybrid suspend (via METHOD override, pasted above) it has not happened for me again (with two night cycles in between, where this bug would usually get triggered).

For me it only happen with close lid. Manual pm-suspend or pm-suspent hybrid works perfectly.

Is there any chance this (and https://bugs.launchpad.net/ubuntu/+source/pm-utils/+bug/1253456) might get fixed in the next months, e.g. for the next LTS release? I would have to downgrade to Ubuntu 12.04 otherwise (or maybe stick to Windows?).

I experience this issue on a MacBook Air when closing the lid. In this case, the network does not come up.
When I use "pm-suspend" to put it to sleep, I get a working network connection after wakeup.

I can't participate directly in this bug anymore because I've done a reinstall.

Having said that, the following configuration now *works* for me.

Ubuntu-Gnome 13.10 install (from scratch)
Gnome-next ppa
Gnome-staging ppa
TLP from https://launchpad.net/~linrunner/+archive/tlp

TLP properly manages my power settings, and gnome-shell suspends via its menus, via the system hotkeys and resume properly brings up the network.

Looks like me like it might be a unity bug or part of the bits that unity depends on, but gnome-shell doesn't.

Philipp, I asked on bug 1253456 for more information, that's a new one. As for this one, I don't have any log files that show any error, nor do I know anyone who can reproduce this. If you still have this bug even with the latest systemd-shim packages, then perhaps looking at network-manager could help:

  sudo stop network-manager
  sudo NetworkManager --log-level=DEBUG --no-daemon 2>&1 | tee /tmp/nm.log

then suspend, resume, let the output settle. Press Control-C, and then

  sudo start network-manager

and attach /tmp/nm.log here.

The last 30 lines of the network manager log as requested.

that 30 lines were not enough. here are 300

When doing "sudo pm-suspend", the log does *not* contain the lines
> [nm-sleep-monitor-systemd.c:150] signal_cb(): Received PrepareForSleep signal: 1
> [nm-manager.c:3511] sleeping_cb(): Received sleeping signal

Christian, that still looks incomplete: the log ends after the suspend, but there is nothing at all after resume?

If you do "pm-suspend" then the PrepareForSleep signal isn't sent, as that's a logind thing.

Christian, I didn't get a system D-BUS monitor log from you yet. If that really is the whole NM log, then for you the PrepareForSleep False signal seems to be missing; please follow https://wiki.ubuntu.com/DebuggingDBus to create a system bus debug log during a suspend cycle. Thanks!

The signal is really missing. Attached is the dbus log when closing and opening the lid.

Thanks Christian. So this is yet another bug than the one that Daniel and Rafael are experiencing.

First, please ensure (dpkg -l systemd-shim) that you have version 6-... installed. If you do, please run this

  sudo G_DBUS_DEBUG=all annotate-output /usr/lib/*/systemd-shim 2>&1 | tee /tmp/systemd-shim.log

then suspend/resume, press Control-C, and attach /tmp/systemd-shim.log here.

Seems that in some cases (1 in 5 tries) networkmanager resumes. Attached is the case when it does not resume.

Note that I don't have to press ctrl+c to stop logging; it exits itself.

Here network manager resumed properly.

So in systemd-shim3.log StartUnit('suspend.target') is called once, while in systemd-shim2.log it's called twice. Are you sure that systemd-shim2.log was the one where things worked properly? It seems much more likely to me that calling StartUnit('suspend.target') twice in short succession might cause problems.

I can't reproduce the working state now with 10 tries. And all those logs of broken resuming only have a single suspend.target call.

I have 6-0ubuntu0.13.10.

Please see the attached nm.log that I created as Martin described in #82.
I had to wait some time after "sudo Networkmanager ..." until my wifi was connected. Then I suspended which took the usual while. After resume, the network was disconnected as usual. I didn't have for any output to settle. I'm not sure, but I think that almost no log entries were added after resume and entering the password.

And here's my systemd-shim.log (see Martin's comment #88). Just like Christian, I do not have to press Ctrl+C, it exits a few moments after resuming and entering the user password.

@pitti
Just an update from my side:
Not using hybrid suspend (via overriding "METHOD=suspend_hybrid") fixed it for me.

Getting this too; I only see one PrepareForSleep true dbus call over a suspend/resume call (no PrepareForSleep false).

Will attach a systemd-shim debug log.

This was captured with the given systemd-shim debug capture rune; I didn't have to ^C systemd-shim on resume as it exited by itself with 0 (see bottom of log).

For completeness, this is grep -C 5 around PrepareForSleep dbus traffic over a suspend/resume:
         string "Strength"
         variant byte 80
      )
   ]
signal sender=:1.23 -> dest=(null destination) serial=2607 path=/org/freedesktop/UPower; interface=org.freedesktop.UPower; member=Changed
signal sender=:1.3 -> dest=(null destination) serial=677 path=/org/freedesktop/login1; interface=org.freedesktop.login1.Manager; member=PrepareForSleep
   boolean true
signal sender=:1.0 -> dest=(null destination) serial=5501 path=/com/ubuntu/Upstart; interface=com.ubuntu.Upstart0_6; member=EventEmitted
   string "backlight-device-changed"
   array [
      string "KERNEL=acpi_video0"

Thanks LoÏc. For the record, it's expected that systemd-shim times out after some seconds of inactivity. So the shim log looks fine, and indeed the PrepareForSleep False is missing, as with other people. At this point this requires an in-depth debugging of systemd-logind, to see why it sometimes fails to send out the PrepareForSleep false after resuming. Supposedly systemd-shim doesn't simulate the suspend.target & friends convincingly enough and we are missing something important there.

I'm not familiar with the inner workings of logind either, so I'm afraid I cannot give much helpful advice what could be wrong there. Just some hints if anyone wants to take a stab:

 - It's perfectly acceptable to kill a running logind and start it in the foreground, even from a built tree; it will pick up the state from /run/ and /sys/fs/cgroups/. That makes it easier for "add debug info"/compile/run/suspend cycles.

 - It's probably also helpful to edit /usr/sbin/pm-suspend to "exit 0" at the start, so that the machine doesn't actually suspend; of course before doing this you should ensure that this actually still reproduces the bug; if not, and it turns out to be some timing issue, then you could also put a "sleep N" in front of it, and check for which values of N it starts working/failing.

So I patched pm-suspend to exit 0, and that would not trigger the bug anymore.

I added a sleep as you suggested and NM would disconnect and then reconnect up to sleep value of 25 but not with sleep values of at least 26. I think we're looking at a 30 seconds timeout since my system takes some seconds to settle from the suspend code pathes (keyboard and display backlights take a couple of seconds to get turned off).

The failing case also differs from the working case in that the screen doesn't turn back on; I guess this is because the signal which we're missing for Network Manager also misses for gnome-screensaver.

So launching logind in the foreground, it displays:
New seat seat0.
Watching system buttons on /dev/input/event3 (Power Button)
Watching system buttons on /dev/input/event7 (Video Bus)
Watching system buttons on /dev/input/event1 (Power Button)
Watching system buttons on /dev/input/event0 (Lid Switch)
Watching system buttons on /dev/input/event2 (Sleep Button)
New session c2 of user lool.
Linked /tmp/.X11-unix/X0 to /run/user/1000/X11-display.

and after a failed fake-suspend, it shows:
Delay lock is active but inhibitor timeout is reached.
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.

This is how debug output looks:
SYSTEMD_LOG_TARGET=console SYSTEMD_LOG_LEVEL=debug annotate-output /lib/systemd/systemd-logind
[...]
18:25:19 E: Fixing up /dev/kvm for seat seat0...
18:25:19 E: Fixing up /dev/rfkill for seat seat0...
18:25:19 E: Fixing up /dev/snd/seq for seat seat0...
18:25:19 E: Fixing up /dev/snd/timer for seat seat0...
18:25:19 E: Inhibitor Telepathy (Disconnecting IM accounts before suspend/shutdown...) pid=16978 uid=1000 mode=delay started.
18:25:19 E: Inhibitor lool (GNOME handling keypresses) pid=4766 uid=1000 mode=block started.
18:25:19 E: systemd-logind running as pid 13421
18:25:27 E: Failed to open configuration file /etc/systemd/sleep.conf: No such file or directory
18:25:32 E: Delay lock is active but inhibitor timeout is reached.
18:25:57 E: 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.

Since the recent update for the Gnome libraries I don't see the bug. The network resumes normally.

It currently doesn't work for me. I have the latest saucy-proposed packages, should the update you mentioned be in there?

This bug still affects me on an up to date saucy, with installed systemd-shim 6-0ubuntu0.13.10.
I also tried systemd-shim in alternative ppa as described in https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262/comments/151

I could only workaround the problem through
http://ubuntuforums.org/showthread.php?t=2182128&p=12830153#post12830153

The same workaround worked for me.
Thanks Massimo !
I really hope that this very annoying bug will be at least resolved for Trusty.

The workaround does not work on my machine.

This Bug still affects me on 12.04

Same here (13.10) . The big problem is that it seems to be in all releases, so downgrading from 13.10 to the previous LTS release wouldn't even help. Half a year ago, everything was fine. So why is it that now it suddenly does not work anymore and can't be fixed (e.g. by reverting some changes)?
For the last two months, I have used Ubuntu less and less often, instead I use Windows a lot more, because it saves me the 15-20 seconds that I need to workaround the issue after resuming Ubuntu.

Btw: Where do bug reports go that I send from within Ubuntu (with the "Report a problem..." application, Apport)? I send tons of these because right after boot I get two errors, sometimes more, and the software updater regularly crashes, too. Maybe this is because my Ubuntu installation is upgraded from 12.10 over 13.04 to 13.10? And may the startup errors be related to this issue?

I have to agree with Philipp, I also, and perhaps somewhat naively, believed it would just be a case of comparing what has changed in newer version with the previous version that didn't have any problem and working out what is causing this problem. Or maybe just reverting to an earlier version of systemd-shim until the problem can be resolved? I'd be happy to test things, I'd even be happy to look over some code and do a spot the difference if that is any good?

I've never had this problem before in any version of Ubuntu that I have used (that I can remember) right back to Warty, so this must be something simple that has recently been changed, right?

Bug affecting me in Ubuntu 14.04

14.04 same thing WIFI won't come back after suspend... Editing /etc/pm/config.d/config with the "SUSPEND_MODULES="your_driver_here"" in my case rtl8192ce.... used to work now its not working at all. After every suspend it seems to be unable to disconnect. The last time WIFI worked at this point was 11.04.... Is anyone reading these??? Why does the below Authenticate and then fail ???? HELP PLEASE I DON't WANT TO RESTART my computer every time I use it....

[ 2014.937326] rtl8192ce: Using firmware rtlwifi/rtl8192cfw.bin
[ 2015.173101] cfg80211: Ignoring regulatory request Set by core since the driver uses its own custom regulatory domain
[ 2015.173438] ieee80211 phy0: Selected rate control algorithm 'rtl_rc'
[ 2015.174204] rtlwifi: wireless switch is on
[ 2016.710890] r8169 0000:09:00.0: eth0: link down
[ 2016.711525] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 2017.076669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 2017.080772] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 2028.174542] wlan0: authenticate with 14:d6:4d:23:76:ee
[ 2028.515770] wlan0: send auth to 14:d6:4d:23:76:ee (try 1/3)
[ 2028.520460] wlan0: authenticated
[ 2043.997218] wlan0: authenticate with 14:d6:4d:23:76:ee
[ 2044.339577] wlan0: send auth to 14:d6:4d:23:76:ee (try 1/3)
[ 2044.540065] wlan0: send auth to 14:d6:4d:23:76:ee (try 2/3)
[ 2044.556494] wlan0: authenticated

On my system (HP ProBook 4750s) it doesn't work since Ubuntu 13.10 update. Now "killall NetworkManager" is my daily routine :)

Justin, I believe you have a different issue; please file a new bug report for it, I suggest filing it against the package 'linux'.

Thanks

Ive collected 3 workarounds, and they work differently. Maybe this would help developers. Also I have lan network printer.

1) suspend via " sudo pm-suspend " - the best option. LAN printer doesnt make a noise and doesnt reinitialise and network continues to work, there ar no notifications about reconnection

2) turn on the password dialog on the wake up. This makes my printer make a noise and networks works too

3)place wakeup script in /etc/pm/sleep.d/ . Printer again reconnects to the computer with noise.

@Seth Arnold, Justin may have the package Linux installed but clearly he is lacking its dependencies:

sarcasm-1.2.1
pretentiousness-99.9
elitism-1.0.1
smugness-1.0.0

Seth you seem to have an extra package installed:

unhelpfulness-0.1.1

Justin, you won’t need to restart every time, you can just enter:

sudo nmcli nm sleep false

or

sudo killall NetworkManager

This is an annoying bug, that you wouldn’t expect to see in Ubuntu these days (I didn't see anything like this from the start) and I would describe it as serious, I mean how many people like Justin would have no idea how to get their networking back? I am guessing most new Ubuntu users, as it is not like they can search the net for a solution is it?

Yanpas, thanks will try 2) as that has to be easier than having to open a terminal each and every time I resume. It also makes me wonder about those that don't have this bug, is it merely because many people have that enabled?

Yes, by default password is on. I think the problem is that network manager needs root password to resume. So that is the trouble. I wonder why it is still unfixed and there are no comments from devs :(

IDK whats going on and thanks to those like SETH, now the bug is so split who knows if it will ever be fixed.... Pablo Thanks for your help... I'm not that much a newb but also not a developer. I know python and work in Networking, but when it comes to Ubuntu application support sorry to say I don't even know where to start...

Yanpas, I tried your workarounds, sorry to say they did not work :( Thanks for your effort though... It would be nice to hear from a dev. How we can signal them? Maybe if we offer money? Hey Devs I'll pay! I will pay you money to help us with a fix.... If I said this to Microsoft they would fix it same day, lol.

Hey Guys Try this work around, It's the only one that worked on my Toshiba NB505 With realtek drivers...

Settings> security & privacy> Uncheck waking from Suspend & Returning From blank screen

Delete the entire contents of the following files "/etc/pm/config.d/config" & "/etc/pm/config.d/unload_modules"

gksu gedit /etc/pm/config.d/config
gksu gedit /etc/pm/config.d/unload_modules

Try a suspend and it should come back.... That said you might want to look around for more edited files in /etc/pm/config.d/

Having said all that I have no Idea why that works. lol

A reinstallation might help. Even though the bug has not been fixed for the new LTS version (....), a fresh installation might help. I didn't do much testing because I uninstalled Ubuntu to free up my SSD space for Windows (which runs rather stable and doesn't give a whole bunch of error messages after login), but for 10 minutes I tested Ubuntu 14.04 from a USB stick, and it didn't have the problem. So maybe if you install it, it won't have the problem either.
However, I do realize that reinstalling the entire OS might not be something you want to do - that's why I'm on Windows now.

Pablo180, this bug is about a missing PrepareForSleep signal from systemd-shim.

Justin's log messages show that his kernel had trouble re-associating with his access point. I have seen several other people with similar log messages and it would be far easier for that problem to be diagnosed and corrected if everyone who experienced that problem would file a bug for it, rather than just add their woes to an existing bug that is completely unrelated despite showing similar symptoms ("network doesn't work").

Thanks.

Seth Arnold, which logs do I need to upload? BTW I use latest systemd-shim 6-2bzr1

Interesting observation - If you check and then uncheck password request after suspend - that will fix the problem till the next reboot. So the final step - how to write .sh script that will check and uncheck this option at every PC boot? (Something related with dconf). Also check if this solution helps you. I think there are several bugs in this topic with the one result.

dconf write /org/gnome/desktop/screensaver/ubuntu-lock-on-suspend true
dconf write /org/gnome/desktop/screensaver/ubuntu-lock-on-suspend false
This two-line script didn't solved my problem...
The last workaround I've invented is to change Command "suspend" from Gear Menu to:
   echo <yourpassword> | sudo -S pm-hibernate

Any suggestions how to do it?

Yanpas, I tried setting the password request upon resume, it didn't make any difference for me. Networking was still down after resuming and entering my password. But I am using 13.10 and only hibernate, I don't suspend, not sure whether that has any bearing.

Seth, if that was the case then I apologise, it looked to me like sarcasm, the kind of sarcasm that I see too often.

Maybe it is gnome-power-manager fault?

Philip, I also tried the Live CD version of 14.04 and discovered the same as you did that it did not suffer from this problem. However I remember some years ago trying the Live CD of a newly released version of Ubuntu and discovered that Suspend and Hibernate worked flawlessly, only to install the same version and discover that they didn’t work at all once Ubuntu was installed. So I don’t trust the Live version enough to attempt a complete re-install, probably only to discover that the problem is still present!

I have upgraded to 14.04 and as others have stated, the problem persists. It seems less frequent, but I think that part of that is that it seems to happen more when it has been suspended for a while, and I have only tested it by repeatedly closing and opening the lid today.

Justin, I looked at your workaround but that folder is empty for me, so I cannot try it.

Yanpas, I tried setting the password again on resume in 14.04, but with the same result as before, it didn’t work for me for Suspend.

I’ve given up to be honest. This will probably be fixed upstream in a year or two. I’ve been using Ubuntu for ten years and can count on one hand the number of bugs I’ve seen fixed. Typically I find a workaround, forget all about and years later realise the problem has gone away.

I am now using a workaround found here: http://ubuntuforums.org/showthread.php?t=1522146

This restarts NetworkManager on every resume. It is not ideal, but it works and is not dependent on anything else and won’t be overridden by an update. Problem solved.

After upgrading to 14.04 I am more affected by this bug than before: network-manager does not wake up properly after hibernation.
With 13.10 this might only happen when I was using overriding the METHOD to METHOD=suspend_hybrid for METHOD=suspend.

The workaround: `sudo nmcli nm sleep false`.

Ubuntu GNOME 14.04
Log like https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1252121/comments/82

Workaround using
/etc/pm/sleep.d/10_restart-networkmanager
works for me with less priority only, e.g. 01_restart... filename.

I've booted from live Xubuntu 14.04 and there were such a bug too! So reinstall won't help

@Dimitry from #131

Unfortunatly for some reason Gnomebuntu doesn't care about /etc/pm/sleep/*, pm-utls is involved with /etc/pm* and pm-utils is not installed under gnomebuntu 14.04 for me. Installing pm-utils makes suspend/resume work much less reliable, so leaving it off.

@oliver so which utility does provide you power management?

@yanpas

I do not know! u-power? something else gnome-specific? I should take some time to investigate what else there is.

14.04, stock installation (no Jupiter or other additional power management software), desktop PC, networking never resumed after a suspend, 100% failure rate. Though being a desktop I supended the PC maybe 10 times since April.

I suppose that problem is invisible for developers. Any ideas how to UP topic?

Good question!

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.

@andi3 Does hibernation work in Utopic? It is disabled for some unknown reasons in ubuntu for a long time, and I miss it very much. In addition to all now I'm back to Windows 7 and waiting for the fix

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

I'm also experiencing this in 14.04 after upgrade from Ubuntu 12; dbus log shows PrepareForSleep true on suspend, but no corresponding PrepareForSleep false on awakening.

Putting a script in /etc/pm/sleep.d/ (or in /usr/lib/pm-utils/sleep.d/) to issue "nmcli nm sleep false" (a workaround suggested elsewhere) doesn't work for me (but I can issue "sudo nmcli nm sleep false" manually to bring the network back).

Creating a /etc/pm/config.d/config file with the command "SUSPEND_MODULES="brcmsmac"" (another suggested workaround) also doesn't do the trick (yes, brcmsmac is my driver, I'm pretty sure anyway).

The same behavior on fresh reinstalled Xubuntu.

Same problem for laptop upgraded from 12.04 into 14.04.

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

@dave-eorbit Thank you anyway!

@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've added the script that I use to this post.

!!! 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?

I'm not sure whether this scipt were posted here.
=====================
#!/bin/bash
case "$1" in
thaw|resume)
nmcli nm sleep false
;;
*)
;;
esac
exit $?
#save it in /etc/pm/sleep.d/wakenet.sh

Is this reproducible on Utopic?

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

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

@Yanapas #148
Yes I have same bug in Linux Mint 17 KDE 64bit

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.

Same feeling, I'm disappointed no one seems to take care of that basic bug that keeps me from using Ubuntu as my daily distro.

@r0lf this is still happening in 14.10/Utopic should it be reopened there?

The issue seems be resolved for me in Lubuntu 14.10.

On Wed Jan 21 2015 at 2:01:06 PM Andy Somerville <email address hidden>
wrote:

> @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
>

If so we are waiting backport of fix to Trusty

It is still happening in Xubuntu 14.10. After coming back from suspend (closed the laptop lid), NetworkManager is asleep:

RUNNING STATE WIFI-HARDWARE WIFI WWAN-HARDWARE WWAN
running asleep enabled enabled enabled disabled

This workaround works for me: created script /etc/pm/sleep.d/49network-manager:

#!/bin/sh
#
# work around a NetworkManager bug, waking it up after resume (sometimes it
# stays sleeping after resume)
#

case "$1" in
    suspend|hibernate)
 ;;

    resume|thaw)
 nmcli nm status
 nmcli dev status
 state=`nmcli -t -f STATE nm status`
 if [ "$state" = "asleep" ]; then
     echo "waking up NetworkManager"
     nmcli nm sleep false
     nmcli nm status
 fi
 ;;
esac

exit 0

I had removed it to test whether the problem had gone away, but put it back when confirmed it hadn't been solved yet.

Maybe it depends on fresh install/update from buggy trusty?

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.

This works fine for me, with wicd on Ubuntu Utopic.

Actually, I don't see why someone (justin parker?) marked wicd as being affected, because I don't see anyone mentioning wicd in this report, and neither in https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1184262 and neither in any of the duplicates.

Marked as Invalid, just let me know if there's a real issue with wicd here.

14.04.2 had been just released with new kernel 3.16 Is the big still persists? And what is wicd? Package that fixes bug ?

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:

suspend to ram - auto
check ready bit - auto
away mode support - disabled

restore on AC - power off
Ring-in power on - disabled
PCI devices power on - disabled
PS/2 Keyboard power on - disabled
RTC alarm - by OS

ACPI HPET Table - disabled

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.

@Pablo have you tried disabling ACPI HPET Table in BIOS? Maybe you don't have such option in BIOS/UEFI.

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

Currently using Xubuntu 14.04.2 updated.
I have tried all the workarounds (restarting services, scripts, unload module files, etc) and none of them work for me.

The issue I experience is related only to wired connection (DSL or Ethernet connections) and *not* with wi-fi.

What I found out and what is not mentioned often is that for me the issue only happens when my laptop is on battery power (battery mode). If the laptop is plugged into AC, no issues.

Network driver = r8169 (Realtek)
Note - wi-fi says disabled, because I disabled it myself. Unlike ethernet, I don't keep the wi-fi always on.

Are there any news about this bug ? Reading all the topics here and on Ubuntu forums, ASK Ubuntu, I see it is present for 2-3 years now ?

Thanks !

    description: Notebook
    product: SATELLITE C50-A (PSCJGE-*******)
    vendor: TOSHIBA
    version: ******
    serial: *******
    width: 64 bits
    capabilities: smbios-2.7 dmi-2.7 vsyscall32
    configuration: boot=normal chassis=notebook family=Durban 10BT sku=PSCJGE-******** uuid=**********
  *-core
       description: Motherboard
       product: Portable PC
       vendor: TOSHIBA
       physical id: 0
       version: MP
       serial: 1
     *-firmware
          description: BIOS
          vendor: INSYDE Corp.
          physical id: 0
          version: 1.10
          date: 12/03/2013
          size: 64KiB
          capacity: 8128KiB
          capabilities: pci pnp upgrade shadowing cdboot bootselect edd int9keyboard int10video acpi usb smartbattery biosbootspecification netboot
     *-cpu
          description: CPU
          product: Intel(R) Celeron(R) CPU N2820 @ 2.13GHz
          vendor: Intel Corp.
          physical id: 4
          bus info: cpu@0
          version: Intel(R) Celeron(R) CPU N2820 @ 2.13GHz
          slot: CPU 1
          size: 2132MHz
          capacity: 4GHz
          width: 64 bits
          clock: 133MHz
          capabilities: x86-64 fpu fpu_exception wp vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf pni pclmulqdq dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm sse4_1 sse4_2 movbe popcnt tsc_deadline_timer rdrand lahf_lm 3dnowprefetch ida arat epb dtherm tpr_shadow vnmi flexpriority ept vpid tsc_adjust smep erms cpufreq
          configuration: cores=4 enabledcores=4 threads=1
        *-cache:0
             description: L1 cache
             physical id: 8
             slot: L1 Cache
             size: 32KiB
             capacity: 32KiB
             capabilities: synchronous internal write-back instruction
        *-cache:1
             description: L2 cache
             physical id: 9
             slot: L2 Cache
             size: 1MiB
             capacity: 1MiB
             capabilities: synchronous internal write-back unified
     *-cache
          description: L1 cache
          physical id: 7
          slot: L1 Cache
          size: 24KiB
          capacity: 24KiB
          capabilities: synchronous internal write-back data
     *-memory
          description: System Memory
          p...

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?

This works perfectly on Ubuntu 16.04 with systemd:

https://gist.github.com/nitely/3d5f10b4f686f5f96c95

I've recently upgraded from 12.04 to 14.04. In 12.04 all worked perfectly.
I see the same sort of thing as discussed. I attach a log from dbus-monitor.

PrepareForSleep True is sent, sleep state is never reached, PrepareForSleep false is never sent

I have no problem suspend/hybernate via pm-suspend.

sudo /lib/systemd/systemd-sleep suspend
also works fine for suspend, hibernate and hybrid-sleep

systemd/network manager get in a mess. seemingly together (see test results below)

Since I'm on 14.04, I don't have systemd-shim, so this seems to be a systemd problem, not just -shim

I used to have tlp installed, but have purged it, and re-installed systemd, the problem has not cleared.

Test results:

$ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
>> network manager disables, no suspend

2nd call:
$ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
Error: GDBus.Error:org.freedesktop.systemd1.LoadFailed: Unit systemd-suspend.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-suspend.service' for details.

$ sudo killall NetworkManager
>> Network returns.

$ sudo gdbus call -y -d org.freedesktop.login1 -o /org/freedesktop/login1 -m org.freedesktop.login1.Manager.Suspend true
>> network manager disables, no suspend

-----------------------------
Test results2:

$ systemctl suspend
>> network manager disables, no suspend (no error msg)

$ systemctl suspend
Failed to issue method call: Unit systemd-suspend.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-suspend.service' for details.
Failed to issue method call: Access denied

$ sudo killall NetworkManager
>> Network returns.
$ systemctl suspend
>> network manager disables, no suspend (no error msg)

$ sudo systemctl status systemd-suspend.service
systemd-suspend.service
   Loaded: error (Reason: No such file or directory)
   Active: inactive (dead)

----------------

$ sudo nmcli nm sleep false
>> NM restarts, however, it is NOT as 'cleansing' as killing NM
As:

$ systemctl suspend
Failed to issue method call: Unit systemd-suspend.service failed to load: No such file or directory. See system logs and 'systemctl status systemd-suspend.service' for details.

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

Dear ubuntu staffs,
installing new softwares in my ubutu I am persistently face with error as below:

dpkg-divert: error: rename involves overwriting '/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service' with
  different file '/usr/share/dbus-1/system-services/org.freedesktop.systemd1.service.systemd', not allowed
dpkg: error processing package systemd-shim (--remove):
 installed systemd-shim package post-removal script subprocess returned error exit status 2
Errors were encountered while processing:
 systemd-shim
E: Sub-process /usr/bin/dpkg returned an error code (1)

please help me solve this problem.
Thanks in advance for your help