touch-packages team mailing list archive

[Martin Pitt <martin.pitt@xxxxxxxxxx>]

** Description changed:

  lxc-stop sends SIGPWR to a container's pid 1 to notify it that it should
  shut down. This merely starts sigpwr.target right now, but nothing is
  hooked into it. That's deliberate for "real iron" systems as there it's
  usually UPSes sending that, which should be handled by e. g. nut, not
  directly systemd. However, for containers I believe that's a safe
  default.
  
  https://lists.linuxcontainers.org/pipermail/lxc-
  users/2015-May/009279.html
  
  SRU TEST CASE:
  --------------
  - Create a vivid LXC container (system or unprivileged)
  - Try to lxc-stop it. With current vivid it will do nothing/hang, with the proposed version it will shut down as expected.
+ 
+ REGRESSION POTENTIAL:
+ ---------------------
+ - This new unit is only active in containers (LXC, docker, nspawn, etc.). There a possible regression is that someone is running/testing nut or a similar UPS responder in a container, but that seems like a theoretical scenario only.
+ - There is no change for VMs or "real" hardware.

** Description changed:

  lxc-stop sends SIGPWR to a container's pid 1 to notify it that it should
  shut down. This merely starts sigpwr.target right now, but nothing is
  hooked into it. That's deliberate for "real iron" systems as there it's
  usually UPSes sending that, which should be handled by e. g. nut, not
  directly systemd. However, for containers I believe that's a safe
  default.
+ 
+ For the record, in upstart we had /etc/init/shutdown.conf . This is
+ wrong, as it breaks UPS responders like nut (and it also halts instead
+ of poweroff). But we should provide this for containers under systemd.
  
  https://lists.linuxcontainers.org/pipermail/lxc-
  users/2015-May/009279.html
  
  SRU TEST CASE:
  --------------
  - Create a vivid LXC container (system or unprivileged)
  - Try to lxc-stop it. With current vivid it will do nothing/hang, with the proposed version it will shut down as expected.
  
  REGRESSION POTENTIAL:
  ---------------------
  - This new unit is only active in containers (LXC, docker, nspawn, etc.). There a possible regression is that someone is running/testing nut or a similar UPS responder in a container, but that seems like a theoretical scenario only.
  - There is no change for VMs or "real" hardware.

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

Title:
  lxc-stop does not shut down container

Status in systemd package in Ubuntu:
  In Progress
Status in systemd source package in Vivid:
  New
Status in systemd source package in Wily:
  In Progress

Bug description:
  lxc-stop sends SIGPWR to a container's pid 1 to notify it that it
  should shut down. This merely starts sigpwr.target right now, but
  nothing is hooked into it. That's deliberate for "real iron" systems
  as there it's usually UPSes sending that, which should be handled by
  e. g. nut, not directly systemd. However, for containers I believe
  that's a safe default.

  For the record, in upstart we had /etc/init/shutdown.conf . This is
  wrong, as it breaks UPS responders like nut (and it also halts instead
  of poweroff). But we should provide this for containers under systemd.

  https://lists.linuxcontainers.org/pipermail/lxc-
  users/2015-May/009279.html

  SRU TEST CASE:
  --------------
  - Create a vivid LXC container (system or unprivileged)
  - Try to lxc-stop it. With current vivid it will do nothing/hang, with the proposed version it will shut down as expected.

  REGRESSION POTENTIAL:
  ---------------------
  - This new unit is only active in containers (LXC, docker, nspawn, etc.). There a possible regression is that someone is running/testing nut or a similar UPS responder in a container, but that seems like a theoretical scenario only.
  - There is no change for VMs or "real" hardware.

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