touch-packages team mailing list archive

[ftoledo <ftoledo@xxxxxxxxxxxxxx>]

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.

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

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

Status in systemd-shim package in Ubuntu:
  New

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/systemd-shim/+bug/1455520/+subscriptions