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.

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