dx-packages team mailing list archive

[D J Gardner <somloieater@xxxxxxxxx>]

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.


** Attachment added: "dbus log, kill NetworkManager, wait, try to suspend, wait, kill N-Mgr"
   https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1252121/+attachment/4810108/+files/dbus.log

** No longer affects: systemd (Ubuntu Saucy)

-- 
You received this bug notification because you are a member of DX
Packages, which is subscribed to systemd-shim in Ubuntu.
https://bugs.launchpad.net/bugs/1252121

Title:
  missing PrepareForSleep signal after resuming, causing networking to
  stay disabled

Status in systemd package in Ubuntu:
  New
Status in systemd-shim package in Ubuntu:
  Confirmed
Status in systemd-shim source package in Saucy:
  Won't Fix
Status in systemd source package in Trusty:
  New
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/ubuntu/+source/systemd/+bug/1252121/+subscriptions