missing PrepareForSleep signal after resuming, causing networking to stay disabled
- Trusty (14.04)
- Bug #1252121
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
systemd (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Trusty |
Won't Fix
|
Undecided
|
Unassigned | ||
systemd-shim (Ubuntu) |
New
|
High
|
Unassigned | ||
Saucy |
Won't Fix
|
High
|
Unassigned | ||
Trusty |
Confirmed
|
High
|
Unassigned |
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:/
Regression potential: Low. Flushing the session bus was introduced in version 4 and is obviously bogus as in a system D-BUS service there is no session bus. This causes lots of confusing error messages and unnecessary overhead like trying to start dbus-launch. Flushing the system bus is low-risk, in most cases it's a no-op and it would otherwise prevent losing signals after waking up. No known regressions.
TEST CASE: Run several suspend/resume cycles with the lid, session indicator menu, and verify that the network comes back up. It is known that this fix is necessary but not sufficient, so it is not expected to fix all cases. But it should not make things worse, so if network now does not come up any more on a machine where it previously worked this would count as failure/regression.
Gabriel A. Devenyi (gadevenyi) wrote : | #1 |
- Dependencies.txt Edit (2.7 KiB, text/plain; charset="utf-8")
- ProcEnviron.txt Edit (106 bytes, text/plain; charset="utf-8")
Gabriel A. Devenyi (gadevenyi) wrote : | #2 |
penalvch (penalvch) wrote : | #3 |
Gabriel Devenyi, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://
apport-collect -p linux <replace-
Also, could you please test the latest upstream kernel available (not the daily folder) following https:/
kernel-
kernel-
where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-
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-
If the mainline kernel does not fix this bug, please add the following tags:
kernel-
kernel-
As well, please remove the tag:
needs-upstream-
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.
Changed in linux (Ubuntu): | |
status: | New → Incomplete |
importance: | Undecided → Medium |
Martin Pitt (pitti) wrote : | #4 |
The "PrepareForSleep false" signal is missing. Invalidating kernel task to stop the kernel bug auto-responder from nagging (please ignore the previous comment).
Changed in linux (Ubuntu): | |
status: | Incomplete → Invalid |
Martin Pitt (pitti) wrote : | #5 |
Can you please modify ("sudo gedit", for example) /usr/share/
Exec=/bin/sh -c 'env G_DBUS_DEBUG=all annotate-output /usr/lib/
Then please do a suspend/resume cycle, and attach /tmp/systemd-
Thanks!
affects: | systemd (Ubuntu) → systemd-shim (Ubuntu) |
Changed in systemd-shim (Ubuntu): | |
status: | New → Incomplete |
Martin Pitt (pitti) wrote : | #6 |
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
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.
Gabriel A. Devenyi (gadevenyi) wrote : | #7 |
Martin, adding the Exec line as requested results in failure of the suspend portion of suspend-resume, so I cannot provide a log
Philipp Keck (philipp-v) wrote : | #8 |
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
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.
Philipp Keck (philipp-v) wrote : | #9 |
- systemd-shim.log Edit (22.2 KiB, text/plain)
I just modified /usr/share/
env: annotate-output: No such file or directory
So I ran "sudo apt-get install devscripts" and retried. See the logfiles attached.
Philipp Keck (philipp-v) wrote : | #10 |
- pm-suspend.log Edit (547.4 KiB, text/plain)
pm-suspend.log after unsuccessful suspend-
Martin Pitt (pitti) wrote : | #11 |
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-
Rafael Levi (rlevi66) wrote : | #12 |
- pm-suspend.log Edit (371.1 KiB, text/plain)
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
Rafael Levi (rlevi66) wrote : | #13 |
Rafael Levi (rlevi66) wrote : | #14 |
Catalin Hritcu (catalin-hritcu) wrote : | #15 |
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.
Gabriel A. Devenyi (gadevenyi) wrote : | #16 |
Gabriel A. Devenyi (gadevenyi) wrote : | #17 |
Martin Pitt (pitti) wrote : | #18 |
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_
(and some noise around it). Rafael's log additionally shows
15:05:35 E: ** (process:19670): WARNING **: Error while running '/usr/sbin/
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.
summary: |
- networkmanager networking is disabled on suspend-resume + missing resume signal because D-BUS connection goes away |
Daniel Lombraña González (teleyinex) wrote : Re: missing resume signal because D-BUS connection goes away | #19 |
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.
Martin Pitt (pitti) wrote : Re: [Bug 1252121] Re: missing resume signal because D-BUS connection goes away | #20 |
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!
Martin Pitt (pitti) wrote : Re: missing resume signal because D-BUS connection goes away | #21 |
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:
14:39:18 O: GDBus-debug:
14:39:18 O: GDBus-debug:
14:39:18 O: GDBus-debug:
14:39:18 O: GDBus-debug:
[...]
14:39:18 O: GDBus-debug:
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:
14:39:18 O: GDBus-debug:Auth: CLIENT: initiating
14:39:18 O: GDBus-debug:Auth: CLIENT: sent credentials 'GCredentials:
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 7a808dc6cc702b9
14:39:18 O: GDBus-debug:Auth: CLIENT: writing 'NEGOTIATE_
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForAgree
14:39:18 O: GDBus-debug:Auth: CLIENT: WaitingForAgree
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=
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.
Changed in systemd-shim (Ubuntu): | |
importance: | Undecided → High |
status: | Incomplete → Triaged |
Martin Pitt (pitti) wrote : | #22 |
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:/
Martin Pitt (pitti) wrote : | #23 |
Please upgrade to my systemd-shim package in https:/
I'll land this upstream and upload an SRU next Monday.
Changed in systemd-shim (Ubuntu): | |
assignee: | nobody → Martin Pitt (pitti) |
status: | Triaged → In Progress |
Gabriel A. Devenyi (gadevenyi) wrote : | #24 |
Unfortunately, this doesn't seem to have fixed it, suspend-resume via the laptop function keys still disabled networking.
Martin Pitt (pitti) wrote : | #25 |
Gabriel, can you please create a new systemd-shim log just like in comment 5?
Gabriel A. Devenyi (gadevenyi) wrote : | #26 |
- systemd-shim log with 5-0ubuntu0.0pitti1 Edit (20.9 KiB, text/plain)
systemd-shim log with 5-0ubuntu0.0pitti1
Gabriel A. Devenyi (gadevenyi) wrote : | #27 |
- pm-suspend log of 5-0ubuntu0.0pitti1 Edit (719.0 KiB, text/plain)
pm-suspend log of 5-0ubuntu0.0pitti1
Martin Pitt (pitti) wrote : | #28 |
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!
Gabriel A. Devenyi (gadevenyi) wrote : | #29 |
Pablo180 (paultait22) wrote : | #30 |
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.
Martin Pitt (pitti) wrote : | #31 |
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?
summary: |
- missing resume signal because D-BUS connection goes away + missing PrepareForSleep signal after resuming, causing networking to + stay disabled |
Changed in systemd-shim (Ubuntu): | |
assignee: | Martin Pitt (pitti) → nobody |
status: | In Progress → Incomplete |
MikeD (mike-dymott) wrote : | #32 |
Thanks for the fix package, which worked for me.
no longer affects: | linux (Ubuntu) |
Martin Pitt (pitti) wrote : | #33 |
> 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.
Neil Olver (neilincanadia) wrote : | #34 |
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?
Gabriel A. Devenyi (gadevenyi) wrote : | #35 |
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...
Pablo180 (paultait22) wrote : | #36 |
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.
Martin Pitt (pitti) wrote : | #37 |
There is no "tlp" package in Ubuntu, also not in earlier releases. What does that do?
Gabriel A. Devenyi (gadevenyi) wrote : | #38 |
http://
Essentially, it's a highly configurable battery/AC profile manager.
Martin Pitt (pitti) wrote : | #39 |
So is everyone for whom the PPA package still does not work using TLP then?
summary: |
- missing PrepareForSleep signal after resuming, causing networking to - stay disabled + with installing TLP: missing PrepareForSleep signal after resuming, + causing networking to stay disabled |
Philipp Keck (philipp-v) wrote : Re: with installing TLP: missing PrepareForSleep signal after resuming, causing networking to stay disabled | #40 |
For me the PPA does not work but I do NOT use TLP. However, I do use "Jupiter" http://
Catalin Hritcu (catalin-hritcu) wrote : | #41 |
I'm not using TLP or Jupiter or powertop, still I have the problem even with the PPA.
Rafael Levi (rlevi66) wrote : | #42 |
I'm using TLP and the bug is still here with 5-0ubuntu0.0pitti1
Matthew Babbs (matt-babbs) wrote : | #43 |
>> 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.
Martin Pitt (pitti) wrote : | #44 |
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:/
summary: |
- with installing TLP: missing PrepareForSleep signal after resuming, - causing networking to stay disabled + missing PrepareForSleep signal after resuming, causing networking to + stay disabled |
Seth Arnold (seth-arnold) wrote : | #45 |
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.
Andrei Levin (andrei-levin) wrote : | #46 |
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.
Rafael Levi (rlevi66) wrote : | #47 |
Rafael Levi (rlevi66) wrote : | #48 |
Gabriel A. Devenyi (gadevenyi) wrote : | #49 |
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..
Martin Pitt (pitti) wrote : | #50 |
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.
Martin Pitt (pitti) wrote : | #51 |
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!
description: | updated |
Launchpad Janitor (janitor) wrote : | #52 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in systemd-shim (Ubuntu Saucy): | |
status: | New → Confirmed |
Launchpad Janitor (janitor) wrote : | #53 |
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
"
resuming. (LP: #1252121)
-- Martin Pitt <email address hidden> Tue, 10 Dec 2013 10:54:18 +0100
Changed in systemd-shim (Ubuntu Trusty): | |
status: | Incomplete → Fix Released |
Changed in systemd-shim (Ubuntu Trusty): | |
status: | Fix Released → Incomplete |
description: | updated |
Stéphane Graber (stgraber) wrote : Please test proposed package | #54 |
Hello Gabriel, or anyone else affected,
Accepted systemd-shim into saucy-proposed. The package will build now and be available at http://
Please help us by testing this new package. See https:/
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-
Further information regarding the verification process can be found at https:/
Changed in systemd-shim (Ubuntu Saucy): | |
status: | Confirmed → Fix Committed |
tags: | added: verification-needed |
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : | #55 |
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.
tags: |
added: verification-failed removed: verification-needed |
Martin Pitt (pitti) wrote : | #56 |
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!
tags: |
added: verification-needed removed: verification-failed |
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : | #57 |
@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.
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : | #58 |
Further, I must add that this issue affects me on every suspend/resume, not intermittantly.
Rafael Levi (rlevi66) wrote : | #59 |
- pm-suspend.log Edit (238.5 KiB, text/plain)
Looks like it wakes up faster but still have the same problem of the network not coming back from suspend.
jhfhlkjlj (fdsuufijjejejejej-deactivatedaccount) wrote : | #60 |
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.
Martin Pitt (pitti) wrote : | #61 |
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.
Daniel Hahler (blueyed) wrote : | #62 |
@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/
# Use suspend_hybrid instead of suspend always (requires patch in pm-utils 1.4.1-13)
if [ "$METHOD" = "suspend" ]; then
METHOD=
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.
tags: |
added: verification-done removed: verification-needed |
Seth Arnold (seth-arnold) wrote : | #63 |
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 (fdsuufijjejeje
So I am marking this verification-done.
Thanks!
Martin Pitt (pitti) wrote : Re: [Bug 1252121] Re: missing PrepareForSleep signal after resuming, causing networking to stay disabled | #64 |
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/
Certainly possible. Hibernation is off by default, and I haven't
seen any logs which explicitly use hybrid suspend.
Daniel Hahler (blueyed) wrote : | #65 |
Daniel Hahler (blueyed) wrote : | #66 |
Daniel Hahler (blueyed) wrote : | #67 |
Setting to Triaged, given my non-TLP logs above.
For what it's worth, it happened again when resuming this morning.
Changed in systemd-shim (Ubuntu Trusty): | |
status: | Incomplete → Triaged |
Martin Pitt (pitti) wrote : | #68 |
Daniel, the logs look fine; can you please add a corresponding system D-BUS debug log? (https:/
(The remainder of this bug is far from triaged -- it's absolutely unclear what breaks on the machines that are still affected)
Changed in systemd-shim (Ubuntu Trusty): | |
status: | Triaged → Incomplete |
Launchpad Janitor (janitor) wrote : | #69 |
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
"
resuming. (helps some people in LP: #1252121)
-- Martin Pitt <email address hidden> Tue, 10 Dec 2013 10:59:08 +0100
Changed in systemd-shim (Ubuntu Saucy): | |
status: | Fix Committed → Fix Released |
Chris Halse Rogers (raof) wrote : Update Released | #70 |
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.
Martin Pitt (pitti) wrote : | #71 |
As promised, reopening the saucy task as well, for the people who are still affected.
Changed in systemd-shim (Ubuntu Saucy): | |
status: | Fix Released → Confirmed |
Daniel Hahler (blueyed) wrote : | #72 |
@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
signal sender=:1.3 -> dest=(null destination) serial=1076 path=/org/
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.
Daniel Hahler (blueyed) wrote : | #73 |
With the normal suspend methd, PrepareForSleep
signal sender=:1.3 -> dest=(null destination) serial=1094 path=/org/
interface=
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
Is it something NetworkManager requires to wake up again?
Martin Pitt (pitti) wrote : Re: [Bug 1252121] Re: missing PrepareForSleep signal after resuming, causing networking to stay disabled | #74 |
Daniel Hahler [2013-12-19 13:11 -0000]:
> I have then suspended and resumed (after a minute maybe), and there's no
> PrepareForSleep
>
> signal sender=:1.3 -> dest=(null destination) serial=1076 path=/org/
> 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!
Martin Pitt (pitti) wrote : | #75 |
Daniel Hahler [2013-12-19 13:24 -0000]:
> With the normal suspend methd, PrepareForSleep
> the network came up again), (together with PrepareForSleep
Interesting. To the other affected people: are you using hybrid
suspend or the "simple" (RAM only) suspend?
> Where is the PrepareForSleep
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 "PrepareForSlee
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
searches for networks/
Pablo180 (paultait22) wrote : | #76 |
Martin, for me this occurs in standard suspend, hybrid suspend and also hibernate.
Daniel Hahler (blueyed) wrote : | #77 |
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).
Rafael Levi (rlevi66) wrote : | #78 |
For me it only happen with close lid. Manual pm-suspend or pm-suspent hybrid works perfectly.
Philipp Keck (philipp-v) wrote : | #79 |
Is there any chance this (and https:/
Christian Weiske (cweiske) wrote : | #80 |
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.
Gabriel A. Devenyi (gadevenyi) wrote : | #81 |
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:/
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.
Martin Pitt (pitti) wrote : | #82 |
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.
Christian Weiske (cweiske) wrote : | #83 |
Christian Weiske (cweiske) wrote : | #84 |
Christian Weiske (cweiske) wrote : | #85 |
When doing "sudo pm-suspend", the log does *not* contain the lines
> [nm-sleep-
> [nm-manager.c:3511] sleeping_cb(): Received sleeping signal
Martin Pitt (pitti) wrote : | #86 |
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:/
Christian Weiske (cweiske) wrote : | #87 |
- dbus-lid.log Edit (103.1 KiB, text/plain)
The signal is really missing. Attached is the dbus log when closing and opening the lid.
Martin Pitt (pitti) wrote : | #88 |
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/
then suspend/resume, press Control-C, and attach /tmp/systemd-
Christian Weiske (cweiske) wrote : | #89 |
- systemd-shim3.log Edit (20.9 KiB, text/plain)
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.
Christian Weiske (cweiske) wrote : | #90 |
Martin Pitt (pitti) wrote : | #91 |
So in systemd-shim3.log StartUnit(
Christian Weiske (cweiske) wrote : | #92 |
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.
Philipp Keck (philipp-v) wrote : | #93 |
- nm.log see comment #82, suspended by clicking the Unity menu item Edit (91.3 KiB, text/plain)
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.
Philipp Keck (philipp-v) wrote : | #94 |
- Suspended using Unity menu Edit (20.9 KiB, text/plain)
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.
Daniel Hahler (blueyed) wrote : | #95 |
@pitti
Just an update from my side:
Not using hybrid suspend (via overriding "METHOD=
Loïc Minier (lool) wrote : | #96 |
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.
Loïc Minier (lool) wrote : | #97 |
- systemd-shim.log Edit (20.9 KiB, text/plain)
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).
Changed in systemd-shim (Ubuntu Trusty): | |
status: | Incomplete → Confirmed |
Loïc Minier (lool) wrote : | #98 |
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/
signal sender=:1.3 -> dest=(null destination) serial=677 path=/org/
boolean true
signal sender=:1.0 -> dest=(null destination) serial=5501 path=/com/
string "backlight-
array [
string "KERNEL=
Martin Pitt (pitti) wrote : | #99 |
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/
- It's probably also helpful to edit /usr/sbin/
Loïc Minier (lool) wrote : | #100 |
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.
Loïc Minier (lool) wrote : | #101 |
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/
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.
Loïc Minier (lool) wrote : | #102 |
This is how debug output looks:
SYSTEMD_
[...]
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/
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/
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.
Rafael Levi (rlevi66) wrote : | #103 |
Since the recent update for the Gnome libraries I don't see the bug. The network resumes normally.
Philipp Keck (philipp-v) wrote : | #104 |
It currently doesn't work for me. I have the latest saucy-proposed packages, should the update you mentioned be in there?
Massimo Rossello (maxrossello) wrote : | #105 |
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:/
I could only workaround the problem through
http://
Aizelauna (aize-launa) wrote : | #106 |
The same workaround worked for me.
Thanks Massimo !
I really hope that this very annoying bug will be at least resolved for Trusty.
Philipp Keck (philipp-v) wrote : | #107 |
The workaround does not work on my machine.
justin parker (s0m3f00l) wrote : | #108 |
This Bug still affects me on 12.04
Philipp Keck (philipp-v) wrote : | #109 |
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?
Pablo180 (paultait22) wrote : | #110 |
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?
Sayantan Das (sayantan13) wrote : | #111 |
Bug affecting me in Ubuntu 14.04
justin parker (s0m3f00l) wrote : | #112 |
- DMESG from WIFI problems in terminal Edit (20.9 KiB, text/plain)
14.04 same thing WIFI won't come back after suspend... Editing /etc/pm/
[ 2014.937326] rtl8192ce: Using firmware rtlwifi/
[ 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(
[ 2017.076669] IPv6: ADDRCONF(
[ 2017.080772] IPv6: ADDRCONF(
[ 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
Anton Statutov (astatutov) wrote : | #113 |
On my system (HP ProBook 4750s) it doesn't work since Ubuntu 13.10 update. Now "killall NetworkManager" is my daily routine :)
Seth Arnold (seth-arnold) wrote : | #114 |
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
Yanpas (yanpaso) wrote : | #115 |
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.
Pablo180 (paultait22) wrote : | #116 |
@Seth Arnold, Justin may have the package Linux installed but clearly he is lacking its dependencies:
sarcasm-1.2.1
pretentiousness
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?
Yanpas (yanpaso) wrote : | #117 |
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 :(
justin parker (s0m3f00l) wrote : | #118 |
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.
justin parker (s0m3f00l) wrote : | #119 |
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/
gksu gedit /etc/pm/
gksu gedit /etc/pm/
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
Philipp Keck (philipp-v) wrote : | #120 |
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.
Seth Arnold (seth-arnold) wrote : | #121 |
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.
Yanpas (yanpaso) wrote : | #122 |
Seth Arnold, which logs do I need to upload? BTW I use latest systemd-shim 6-2bzr1
Yanpas (yanpaso) wrote : | #123 |
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.
Yanpas (yanpaso) wrote : | #124 |
dconf write /org/gnome/
dconf write /org/gnome/
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?
Pablo180 (paultait22) wrote : | #125 |
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.
Yanpas (yanpaso) wrote : | #126 |
Maybe it is gnome-power-manager fault?
Pablo180 (paultait22) wrote : | #127 |
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://
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.
Daniel Hahler (blueyed) wrote : | #128 |
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=
The workaround: `sudo nmcli nm sleep false`.
Dmitry Voronin (dimka665) wrote : | #129 |
Ubuntu GNOME 14.04
Log like https:/
Dmitry Voronin (dimka665) wrote : | #131 |
Workaround using
/etc/pm/
works for me with less priority only, e.g. 01_restart... filename.
Yanpas (yanpaso) wrote : | #132 |
I've booted from live Xubuntu 14.04 and there were such a bug too! So reinstall won't help
oliver (oliver-schinagl) wrote : | #133 |
@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.
Yanpas (yanpaso) wrote : | #134 |
@oliver so which utility does provide you power management?
oliver (oliver-schinagl) wrote : | #135 |
@yanpas
I do not know! u-power? something else gnome-specific? I should take some time to investigate what else there is.
Leonardo Donelli (learts92) wrote : | #136 |
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.
Yanpas (yanpaso) wrote : | #137 |
I suppose that problem is invisible for developers. Any ideas how to UP topic?
A. Eibach (andi3) wrote : | #138 |
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.
Yanpas (yanpaso) wrote : | #139 |
@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
A. Eibach (andi3) wrote : | #140 |
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. :)
David Gross (dave-eorbit) wrote : | #141 |
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/
Creating a /etc/pm/
Yanpas (yanpaso) wrote : | #142 |
The same behavior on fresh reinstalled Xubuntu.
Vincas Dargis (talkless) wrote : | #143 |
Same problem for laptop upgraded from 12.04 into 14.04.
Benjamin Xiao (ben-r-xiao) wrote : | #144 |
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.
David Gross (dave-eorbit) wrote : | #145 |
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...
Yanpas (yanpaso) wrote : | #146 |
@dave-eorbit Thank you anyway!
Pablo180 (paultait22) wrote : | #147 |
- Script for restarting networking manager on resume Edit (191 bytes, text/plain)
@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.
Yanpas (yanpaso) wrote : | #148 |
!!! 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?
Yanpas (yanpaso) wrote : | #149 |
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/
Yanpas (yanpaso) wrote : | #150 |
Is this reproducible on Utopic?
Paulo Marcel Coelho Aragão (marcelpaulo) wrote : | #151 |
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).
Rolf Leggewie (r0lf) wrote : | #152 |
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".
Changed in systemd-shim (Ubuntu Saucy): | |
status: | Confirmed → Won't Fix |
hirax (hennoh) wrote : | #153 |
@Yanapas #148
Yes I have same bug in Linux Mint 17 KDE 64bit
Brian G. Marete (bgmarete) wrote : | #154 |
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.
Denis Prost (denis-prost) wrote : | #155 |
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.
Andrew Somerville (andy-somerville) wrote : | #156 |
@r0lf this is still happening in 14.10/Utopic should it be reopened there?
Seth Goldin (sethgoldin) wrote : | #157 |
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:/
>
> 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:/
> 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:/
>
Yanpas (yanpaso) wrote : | #158 |
If so we are waiting backport of fix to Trusty
Paulo Marcel Coelho Aragão (marcelpaulo) wrote : | #159 |
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/
#!/bin/sh
#
# work around a NetworkManager bug, waking it up after resume (sometimes it
# stays sleeping after resume)
#
case "$1" in
suspend|
;;
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.
Yanpas (yanpaso) wrote : | #160 |
Maybe it depends on fresh install/update from buggy trusty?
Sergio Callegari (callegar) wrote : | #162 |
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.
Changed in wicd: | |
status: | New → Incomplete |
importance: | Undecided → Medium |
assignee: | nobody → Tom Van Braeckel (tomvanbraeckel) |
status: | Incomplete → Invalid |
Pieter Leclerc (pieterleclerc-deactivatedaccount) wrote : | #163 |
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:/
Marked as Invalid, just let me know if there's a real issue with wicd here.
Yanpas (yanpaso) wrote : | #165 |
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 ?
Yanpas (yanpaso) wrote : | #166 |
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
Pablo180 (paultait22) wrote : | #167 |
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.
Pablo180 (paultait22) wrote : | #168 |
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.
Yanpas (yanpaso) wrote : | #169 |
@Pablo have you tried disabling ACPI HPET Table in BIOS? Maybe you don't have such option in BIOS/UEFI.
Yanpas (yanpaso) wrote : | #170 |
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
Spasov2015 (spasov2015-deactivatedaccount) wrote : | #171 |
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
vendor: INSYDE Corp.
physical id: 0
version: 1.10
date: 12/03/2013
size: 64KiB
capacity: 8128KiB
*-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
*-cache:0
slot: L1 Cache
size: 32KiB
*-cache:1
slot: L2 Cache
size: 1MiB
*-cache
physical id: 7
slot: L1 Cache
size: 24KiB
capacity: 24KiB
*-memory
p...
Magnus (magnusem) wrote : | #172 |
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?
affects: | network-manager → ubuntu-translations |
no longer affects: | ubuntu-translations |
affects: | wicd → ubuntu-translations |
no longer affects: | ubuntu-translations |
Changed in systemd-shim (Ubuntu Saucy): | |
importance: | Undecided → High |
Fabio C. Barrionuevo (luzfcb) wrote : | #173 |
This works perfectly on Ubuntu 16.04 with systemd:
D J Gardner (djgardner) wrote : | #174 |
- dbus log, kill NetworkManager, wait, try to suspend, wait, kill N-Mgr Edit (151.1 KiB, text/plain)
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/
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
>> network manager disables, no suspend
2nd call:
$ sudo gdbus call -y -d org.freedesktop
Error: GDBus.Error:
$ sudo killall NetworkManager
>> Network returns.
$ sudo gdbus call -y -d org.freedesktop
>> 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-
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-
systemd-
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-
no longer affects: | systemd (Ubuntu Saucy) |
Launchpad Janitor (janitor) wrote : | #175 |
Status changed to 'Confirmed' because the bug affects multiple users.
Changed in systemd (Ubuntu Trusty): | |
status: | New → Confirmed |
Changed in systemd (Ubuntu): | |
status: | New → Confirmed |
kasra (kasraahmadian) wrote : | #177 |
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/
different file '/usr/share/
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
Changed in systemd-shim (Ubuntu): | |
status: | Confirmed → New |
Changed in systemd (Ubuntu): | |
status: | Confirmed → Fix Released |
Changed in systemd (Ubuntu Trusty): | |
status: | Confirmed → Won't Fix |
Dbus log during suspend-resume as per https:/ /wiki.ubuntu. com/DebuggingDB us