dx-packages team mailing list archive

[Loïc Minier <lool@xxxxxxxx>]

This is how debug output looks:
SYSTEMD_LOG_TARGET=console SYSTEMD_LOG_LEVEL=debug annotate-output /lib/systemd/systemd-logind
[...]
18:25:19 E: Fixing up /dev/kvm for seat seat0...
18:25:19 E: Fixing up /dev/rfkill for seat seat0...
18:25:19 E: Fixing up /dev/snd/seq for seat seat0...
18:25:19 E: Fixing up /dev/snd/timer for seat seat0...
18:25:19 E: Inhibitor Telepathy (Disconnecting IM accounts before suspend/shutdown...) pid=16978 uid=1000 mode=delay started.
18:25:19 E: Inhibitor lool (GNOME handling keypresses) pid=4766 uid=1000 mode=block started.
18:25:19 E: systemd-logind running as pid 13421
18:25:27 E: Failed to open configuration file /etc/systemd/sleep.conf: No such file or directory
18:25:32 E: Delay lock is active but inhibitor timeout is reached.
18:25:57 E: Failed to send delayed message: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

-- 
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-shim” package in Ubuntu:
  Confirmed
Status in “systemd-shim” source package in Saucy:
  Confirmed
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-shim/+bug/1252121/+subscriptions