Discussion:
sigpwr.target - intended usage?
(too old to reply)
Christian Hofstaedtler
2016-07-16 15:22:18 UTC
Permalink
Hi,

I'm trying to understand how sigpwr.target is intended to be used,
but couldn't find a good explanation. systemd.special says this
target is invoked in a power fail situation, but what should happen
then?

Debian, Ubuntu and PLD install "sigpwr-container-shutdown.service",
which for ConditionVirtualization=container runs systemctl
--no-block poweroff, i.e. triggers a shutdown for containers. For
"normal" hardware, nothing appears to be triggered.

I could not find any services installed by Fedora or openSuSE, but
maybe I was looking in the wrong places.

I'm now somewhat assuming there should be a default "policy" service
that causes sigpwr.target to initiate a shutdown?

Pointers/hints on what is expected behaviour from sigpwr.target
would be highly appreciated.

Thanks,
--
christian hofstaedtler
Lennart Poettering
2016-07-18 10:36:21 UTC
Permalink
Post by Christian Hofstaedtler
Hi,
I'm trying to understand how sigpwr.target is intended to be used,
but couldn't find a good explanation. systemd.special says this
target is invoked in a power fail situation, but what should happen
then?
Debian, Ubuntu and PLD install "sigpwr-container-shutdown.service",
which for ConditionVirtualization=container runs systemctl
--no-block poweroff, i.e. triggers a shutdown for containers. For
"normal" hardware, nothing appears to be triggered.
I could not find any services installed by Fedora or openSuSE, but
maybe I was looking in the wrong places.
I'm now somewhat assuming there should be a default "policy" service
that causes sigpwr.target to initiate a shutdown?
Pointers/hints on what is expected behaviour from sigpwr.target
would be highly appreciated.
My recommendatin: don't bother with SIGPWR. Traditionally on UNIX UPS
software sends SIGPWR to PID 1 to initiate some special kind of
shutdown operation. But it's very vaguely defined only, and one
wonders why a normal shutdown isn't enough here, and why to bounce
this off PID 1 with a special UNIX signal even...

I am pretty sure that power management software that runs in userspace
really shouldn't make use of this anymore. It should just request a
normal shutdown. The only reason why one would want to bother with
SIGPWR at all is that some really power-related old kernel drivers
send SIGPWR to PID 1 too.

From the systemd PoV: this stuff is ugly legacy crap that only exists
for historic reasons and was never really well-defined in its
behavour. It mostly appears to be a concept that exists only because
Linux never had a useful IPC that was accessible from both kernelspace
and userspace in a sane way... In systemd, we don't want anything to
do with it, but some legacy folks really think it's superduper
important. Hence we simply map it to a target unit, and enable users
to map it to whatever they want to map it, but don't do anything smart
about it at all on our own.

I think it would be best of people would just forget about it...

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2016-07-18 11:37:32 UTC
Permalink
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?

https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Post by Lennart Poettering
Post by Christian Hofstaedtler
Hi,
I'm trying to understand how sigpwr.target is intended to be used,
but couldn't find a good explanation. systemd.special says this
target is invoked in a power fail situation, but what should happen
then?
Debian, Ubuntu and PLD install "sigpwr-container-shutdown.service",
which for ConditionVirtualization=container runs systemctl
--no-block poweroff, i.e. triggers a shutdown for containers. For
"normal" hardware, nothing appears to be triggered.
I could not find any services installed by Fedora or openSuSE, but
maybe I was looking in the wrong places.
I'm now somewhat assuming there should be a default "policy" service
that causes sigpwr.target to initiate a shutdown?
Pointers/hints on what is expected behaviour from sigpwr.target
would be highly appreciated.
My recommendatin: don't bother with SIGPWR. Traditionally on UNIX UPS
software sends SIGPWR to PID 1 to initiate some special kind of
shutdown operation. But it's very vaguely defined only, and one
wonders why a normal shutdown isn't enough here, and why to bounce
this off PID 1 with a special UNIX signal even...
I am pretty sure that power management software that runs in userspace
really shouldn't make use of this anymore. It should just request a
normal shutdown. The only reason why one would want to bother with
SIGPWR at all is that some really power-related old kernel drivers
send SIGPWR to PID 1 too.
From the systemd PoV: this stuff is ugly legacy crap that only exists
for historic reasons and was never really well-defined in its
behavour. It mostly appears to be a concept that exists only because
Linux never had a useful IPC that was accessible from both kernelspace
and userspace in a sane way... In systemd, we don't want anything to
do with it, but some legacy folks really think it's superduper
important. Hence we simply map it to a target unit, and enable users
to map it to whatever they want to map it, but don't do anything smart
about it at all on our own.
I think it would be best of people would just forget about it...
Lennart
--
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
https://lists.freedesktop.org/mailman/listinfo/systemd-devel
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2016-07-18 11:54:26 UTC
Permalink
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...

systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2016-07-18 12:00:29 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...
systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).
lxc containers require sigpwr.target to be hooked up properly,
otherwise lxc-stop does not shutdown the container.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
2016-07-18 12:41:01 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...
systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).
lxc containers require sigpwr.target to be hooked up properly,
otherwise lxc-stop does not shutdown the container.
SIGPWR is wired up in sysvinit and upstart by default to initiate a
shutdown. Afaics both do not react on SIGRTMIN+4.

So the problem here is that lxc doesn't know what runs inside the
container: could be an older version of Debian (using syvinit), and
older version of Ubuntu (using upstart) or systemd.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2016-07-18 13:02:10 UTC
Permalink
Post by Michael Biebl
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...
systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).
lxc containers require sigpwr.target to be hooked up properly,
otherwise lxc-stop does not shutdown the container.
SIGPWR is wired up in sysvinit and upstart by default to initiate a
shutdown. Afaics both do not react on SIGRTMIN+4.
Well, many sysvinit distros where set up to log something about
"IMPENDING POWER FAILURE" on SIGPWR... It sounds really wrong to
trigger this in a container just to shut it down...
Post by Michael Biebl
So the problem here is that lxc doesn't know what runs inside the
container: could be an older version of Debian (using syvinit), and
older version of Ubuntu (using upstart) or systemd.
Well, if they don't want to make SIGRTMIN+4 the default because they
think sysvinit/Upstart is more relevant than systemd, then that's
their right. But I think making the kill signal configurable per
container would probably be a good idea. That's what we do in nspawn,
where SIGRTMIN+3 is the default, but you can override it with
--kill-signal= on the cmdline (or KillSignal= in .nspawn files), for
compat with sysv.

Lennart
--
Lennart Poettering, Red Hat
Clemens Gruber
2016-07-18 13:17:55 UTC
Permalink
Hi,
Post by Lennart Poettering
Well, if they don't want to make SIGRTMIN+4 the default because they
think sysvinit/Upstart is more relevant than systemd, then that's
their right. But I think making the kill signal configurable per
container would probably be a good idea. That's what we do in nspawn,
where SIGRTMIN+3 is the default, but you can override it with
--kill-signal= on the cmdline (or KillSignal= in .nspawn files), for
compat with sysv.
I am also sending SIGPWR from a power related kernel module to PID 1 and
I hooked a service which calls "systemctl poweroff -f" to sigpwr.target.

If I instead send SIGRTMIN+4, this would be equivalent to calling
systemctl poweroff which takes too long in my use case (power loss
imminent due to overcurrent or undervoltage situations in an embedded
system, triggered by an interrupt. In the interrupt handler, I send the
SIGPWR signal at the moment).

Would sending SIGRTMIN+14 to PID 1 be identical to calling "systemctl
poweroff --force" ?

Thanks,
Clemens
Lennart Poettering
2016-07-18 14:09:40 UTC
Permalink
Post by Clemens Gruber
Hi,
Post by Lennart Poettering
Well, if they don't want to make SIGRTMIN+4 the default because they
think sysvinit/Upstart is more relevant than systemd, then that's
their right. But I think making the kill signal configurable per
container would probably be a good idea. That's what we do in nspawn,
where SIGRTMIN+3 is the default, but you can override it with
--kill-signal= on the cmdline (or KillSignal= in .nspawn files), for
compat with sysv.
I am also sending SIGPWR from a power related kernel module to PID 1 and
I hooked a service which calls "systemctl poweroff -f" to
sigpwr.target.
To me this really appears backwards... Having kernel code request some
operation from userspace like this is the wrong way around. Instead, I
figure there should be some userspace component that listens to events
from the kernel and then acts on it, asking systemd to shut down...

But anyway, precisely to cover for kernel code like this we stay out
of SIGPWR handling really, and allow the user to turn this into
anything he likes by passing this to a target that may be defined
freely.

If all you want to do on SIGPWR is shut down the system I think the
easiest would be to just add a symlink
/etc/systemd/system/sigpwr.target →
/usr/lib/systemd/system/poweroff.target.
Post by Clemens Gruber
If I instead send SIGRTMIN+4, this would be equivalent to calling
systemctl poweroff which takes too long in my use case (power loss
imminent due to overcurrent or undervoltage situations in an embedded
system, triggered by an interrupt. In the interrupt handler, I send the
SIGPWR signal at the moment).
Would sending SIGRTMIN+14 to PID 1 be identical to calling "systemctl
poweroff --force" ?
Yes.

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2016-07-18 13:34:00 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...
systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).
lxc containers require sigpwr.target to be hooked up properly,
otherwise lxc-stop does not shutdown the container.
SIGPWR is wired up in sysvinit and upstart by default to initiate a
shutdown. Afaics both do not react on SIGRTMIN+4.
Well, many sysvinit distros where set up to log something about
"IMPENDING POWER FAILURE" on SIGPWR... It sounds really wrong to
trigger this in a container just to shut it down...
I do not really disagreeing here. I'm just trying to understand the
current situation.
Post by Lennart Poettering
Post by Michael Biebl
So the problem here is that lxc doesn't know what runs inside the
container: could be an older version of Debian (using syvinit), and
older version of Ubuntu (using upstart) or systemd.
Well, if they don't want to make SIGRTMIN+4 the default because they
think sysvinit/Upstart is more relevant than systemd, then that's
their right. But I think making the kill signal configurable per
container would probably be a good idea. That's what we do in nspawn,
where SIGRTMIN+3 is the default, but you can override it with
--kill-signal= on the cmdline (or KillSignal= in .nspawn files), for
compat with sysv.
I was told that this is already configurable in lxc via lxc.haltsignal.
So afaics, lxc-create would just need to make sure to set this
accordingly on distros which use systemd by default.

Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Michael Biebl
2016-07-18 14:37:49 UTC
Permalink
Post by Michael Biebl
I was told that this is already configurable in lxc via lxc.haltsignal.
So afaics, lxc-create would just need to make sure to set this
accordingly on distros which use systemd by default.
FYI: I've filed https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=831691
Let's see if we can reach some conclusion here.

Regards,
Michael
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2016-07-18 12:46:50 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...
systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).
lxc containers require sigpwr.target to be hooked up properly,
otherwise lxc-stop does not shutdown the container.
I'd really recommend them to switch to SIGRMIN+4 instead. Redefining
the meaning of SIGPWR like they are doing is certainly a bad idea.

Note that this is even documented here since a long time:

https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/

My recommendation would be for the LXC folks to actually have a look
at this document. All of what this lists is container manager agnostic
and should be pretty common sense, and fully implemented by
systemd. If they adopt this they wouldn't have to alter systemd's
default install at all anymore, and things would just work for them in
a container... And most importantly: any container image prepared from
any distribution that uses systemd would just work...

I mean, there's a reason why I put that doc together: to make it easy
for containre managers to "just work" with systemd.

Lennart
--
Lennart Poettering, Red Hat
Michael Biebl
2016-07-18 12:51:55 UTC
Permalink
Post by Lennart Poettering
I'd really recommend them to switch to SIGRMIN+4 instead. Redefining
the meaning of SIGPWR like they are doing is certainly a bad idea.
https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
Hm, the wiki recommends to use SIGRMIN+3, not 4.
--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
Lennart Poettering
2016-07-18 13:00:50 UTC
Permalink
Post by Michael Biebl
Post by Lennart Poettering
I'd really recommend them to switch to SIGRMIN+4 instead. Redefining
the meaning of SIGPWR like they are doing is certainly a bad idea.
https://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/
Hm, the wiki recommends to use SIGRMIN+3, not 4.
either is fine... One is "halt" and one is "poweorff"... In a
container that's kinda the same thing...

Lennart
--
Lennart Poettering, Red Hat
Michael Chapman
2016-07-18 13:23:18 UTC
Permalink
Post by Lennart Poettering
Post by Michael Biebl
Post by Lennart Poettering
Post by Michael Biebl
Apparently SIGPWR is used by lxc-stop to shut down LXC containers.
What interface would you recommend instead?
https://lists.linuxcontainers.org/pipermail/lxc-users/2015-May/009279.html
Is that actually really used? I mean, upstart is pretty much dead
afaics...
systemd since day one shuts down cleanly on SIGRTMIN+4, and it's
probably what a container manager should use (it is what machined
uses). See the "Signals" section in systemd(1).
lxc containers require sigpwr.target to be hooked up properly,
otherwise lxc-stop does not shutdown the container.
I'd really recommend them to switch to SIGRMIN+4 instead. Redefining
the meaning of SIGPWR like they are doing is certainly a bad idea.
On the other hand, wiring up sigpwr.target to pull in poweroff.target
would require no changes to the systemd code, or to anybody else's code
that happens to be using that signal correctly *or* erroneously. It's not
as if SIGPWR has any existing defined use on systemd that would be broken
by such a change -- we may as well make it do the same thing as sysvinit
since we can.

- Michael
Loading...