systemd-shim executes 'poweroff' after resuming from suspend-to-memory(S3)

Bug #1455520 reported by chenyu
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
systemd-shim (Ubuntu)
New
Undecided
Unassigned

Bug Description

Hi,all
I'm using latest kernel 4.1-rc3 on ubuntu 14.04.2 LTS X86_64,
and I found that, after resuming from suspend-to-memory,
the systemd-shim deamon will execute a 'poweroff', which
shuts the system down.

here's my step to reproduce the bug:

1.echo mem > /sys/power/state //ok
2.wait for 30 seconds //ok
3.push power button //ok
4.system resumes automatically //ok
5.after a few seconds, system shutdown //oh no...

I replace /sbin/shutdown with a script that prints the current process backtrace by pstree, then the system will not halt after resumming from suspend-to-memory. Here's my script:

# cat /sbin/shutdown
#!/bin/sh
pstree -a > /home/chenyu/shutdown_trace.log

and here's the backtrace when system is executing my 'shutdown', after resumming, we can see that, systemd-shim invokes 'sh -c /sbin/poweroff':

init
  |-ModemManager
  | `-2*[{ModemManager}]
  |-NetworkManager
  | `-3*[{NetworkManager}]
  |-acpid -c /etc/acpi/events -s /var/run/acpid.socket
  | `-sh -c /etc/acpi/powerbtn.sh
  |-anacron -s
  |-avahi-daemon
  | `-avahi-daemon
  |-bluetoothd
  |-cron
  |-cups-browsed
  |-cupsd -f
  | `-dbus dbus://
  |-dbus-daemon --system --fork
  |-getty -8 38400 tty4
  |-getty -8 38400 tty5
  |-getty -8 38400 tty2
  |-getty -8 38400 tty3
  |-getty -8 38400 tty6
  |-irqbalance
  |-kerneloops
  |-login --
  | `-bash
  | `-sudo -s
  | `-bash
  |-ondemand /etc/init.d/ondemand background
  | `-sleep 60
  |-polkitd --no-debug
  | `-2*[{polkitd}]
  |-rsyslogd
  | `-3*[{rsyslogd}]
  |-sshd -D
  |-systemd-logind
  |-systemd-shim
  | |-sh -c /sbin/poweroff
  | | `-shutdown /sbin/shutdown -h -P now
  | | `-pstree -a
  | `-2*[{systemd-shim}]
  |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | `-systemd-udevd --daemon
  |-upstart-file-br --daemon
  |-upstart-socket- --daemon
  |-upstart-udev-br --daemon
  `-whoopsie
      `-2*[{whoopsie}]

Since I'm not sure why systemd-shim act like this, I would be
happy to debug with your suggestion, and give feedback to you.

Best Regards,
Yu

Revision history for this message
chenyu (chenyu105) wrote :

update 2015 05 16
It seems that, dbus-deamon has received a poweroff meesage then it fork the systemd-shim to shutdown the system, here's the backtrace for systemd-shim . we can see that ,dbus-daemon --system --fork leverage systemd-shim to perform the poweroff.
however, who sends the poweroff message to dbus-daemon???

init
  |-ModemManager
  | `-2*[{ModemManager}]
  |-NetworkManager
  | |-dhclient -d -sf /usr/lib/NetworkManager/nm-dhcp-client.action -pf ...
  | |-dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces--pid-file=/run/sendsigs.omit.d/network-manager.dnsm
  | `-3*[{NetworkManager}]
  |-acpid -c /etc/acpi/events -s /var/run/acpid.socket
  | `-sh -c /etc/acpi/powerbtn.sh
  | `-powerbtn.sh /etc/acpi/powerbtn.sh
  |-avahi-daemon
  | `-avahi-daemon
  |-bluetoothd
  |-cron
  |-cups-browsed
  |-cupsd -f
  | `-dbus dbus://
  |-dbus-daemon --system --fork
  | `-dbus-daemon --system --fork
  | `-systemd-shim /usr/lib/x86_64-linux-gnu/systemd-shim
  | `-pstree -a
  |-getty -8 38400 tty4
  |-getty -8 38400 tty5
  |-getty -8 38400 tty2
  |-getty -8 38400 tty3
  |-getty -8 38400 tty6
  |-irqbalance
  |-kerneloops
  |-login --
  | `-bash
  | `-sudo -s
  | `-bash
  |-polkitd --no-debug
  | `-2*[{polkitd}]
  |-rsyslogd
  | `-3*[{rsyslogd}]
  |-sshd -D
  |-systemd-logind
  |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | |-systemd-udevd --daemon
  | `-systemd-udevd --daemon
  |-upstart-file-br --daemon
  |-upstart-socket- --daemon
  |-upstart-udev-br --daemon
  `-whoopsie
      `-2*[{whoopsie}]

Revision history for this message
ftoledo (ftoledo) wrote :

I have same behavior on debian jessie
it's occurs only where resume from ram..but not if resume from disk (hibernate)

i try to insolae the problem. i start with mate-power-manager (from mate-desktop):
https://github.com/mate-desktop/mate-power-manager/issues/140
But seems that it's not their fault

i think that when resume pressing the powerbutton , its wakeup the machine but also send the poweroff event that poweroff the machine after 20 or 30 seconds.

Revision history for this message
Raphaƫl Payen (rafpayen) wrote :

I have a very similar problem, but my laptop doesn't go through /sbin/shutdown: it turns off abruptly as if I had pulled the power plug. Always after 1 minute exactly.

I'd like to investigate this, if anyone has any idea what to try please tell me. I suspect it is related to Intel Rapid Start, but I already deactivated it in the bios.

Revision history for this message
ftoledo (ftoledo) wrote :

Yes, exactly same behavior as @raff comment.

The iRst are disabled or enabled do not solved it.
Also, i do not have systemd-shim package installed on my debian (actual stretch)

Another behavior that i think are realated to this issue at my machine are:

if i poweroff (shutdown command or touch the porwer button) and the AC adapter IS connect.. the computer reboot 2 or 3 seconds after the system poweroff.

If the AC adacte is DIsconnected the computer power off as expected.

yes, i known that is another bug, but i can bet a beer that is related.

Revision history for this message
ftoledo (ftoledo) wrote :

I still have this issue on debian stretch.

Did someone fix it?

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.