Bug 90479

Summary:	dbus-deamon poweroff the system after resumming from suspend-to-memory
Product:	dbus	Reporter:	yu.c.chen <yu.c.chen>
Component:	core	Assignee:	D-Bus Maintainers <dbus>
Status:	RESOLVED NOTOURBUG	QA Contact:	D-Bus Maintainers <dbus>
Severity:	normal
Priority:	medium
Version:	1.6
Hardware:	x86-64 (AMD64)
OS:	Linux (All)
Whiteboard:
i915 platform:		i915 features:

Description yu.c.chen@intel.com 2015-05-16 13:40:57 UTC

I'm using linux kernel 4.1-rc3 on ubuntu 14.04.2 LTS X86_64,
with dbus 1.6.18-0ubuntu4.3, and I found that, after resuming 
from suspend-to-memory,the system shutdown automatically:


1. echo mem > /sys/power/state
2. wait for 20 seconds
3. wake system up by pushing power button
4. wait for resumming of system
5. after resumming from suspend, the system shutdown automatically


After investigation, I found that, as soon as system resumes from suspending,one suspicious component(maybe a process) sends a 'poweroff' message to dbus-deamon, then dbus-deamon leverages systemd-shim to perform a 'poweroff' operation, which unexpectedly shuts the system down. I don't know in which situation the dbus-deamon will receive a poweroff command, so I post my question here and hope someone familiar with this could give me some method on how to find the killer.

Here's the backtrace of the poweroff flow after resumming from the suspend-to-memory(using 'pstree -a' )

1. dbus-daemon receives a message:

|-dbus-daemon --system --fork
  | `-dbus-daemon --system --fork
  | `-systemd-shim /usr/lib/x86_64-linux-gnu/systemd-shim
  | `-pstree -a



2. the systemd-shim performs the shutdown command:

|-systemd-shim
  | |-sh -c /sbin/poweroff
  | | `-shutdown /sbin/shutdown -h -P now
  | | `-pstree -a



Any comment would be appreciate, and I'd be happy to test as you suggest.

Best Regards,
Yu

Comment 1 Thiago Macieira 2015-05-16 22:19:42 UTC

Your description makes it clear this is not a bug in D-Bus. It receives the message and passes it on to the destination. That means D-Bus is working properly.

To debug your problem, you need to find the process that sent the command and why it did that. You may try running dbus-daemon in verbose mode so it will print the details of the incoming message. Alternatively, you can use strace to get the details of the message as it writes to the destination and that will include the sender's unique connection ID.

Also note that there must be a file in /etc/dbus-1/system.d allowing this sender to send this message to the destination. So the actual source mustn't be very difficult to find.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.