Re: [systemd-devel] sigpwr.target - intended usage?

[Michael Biebl]

2016-07-18 15:34 GMT+02:00 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Lennart Poettering]

On Mon, 18.07.16 15:17, Clemens Gruber (clemens.gru...@pqgruber.com) wrote:

> Hi,
> 
> On Mon, Jul 18, 2016 at 03:02:10PM +0200, Lennart Poettering wrote:
> > 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.

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Michael Chapman]

On Mon, 18 Jul 2016, Lennart Poettering wrote:

On Mon, 18.07.16 14:00, Michael Biebl (mbi...@gmail.com) wrote:


2016-07-18 13:54 GMT+02:00 Lennart Poettering :

On Mon, 18.07.16 13:37, Michael Biebl (mbi...@gmail.com) wrote:


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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Michael Biebl]

2016-07-18 15:02 GMT+02:00 Lennart Poettering :
> On Mon, 18.07.16 14:41, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 2016-07-18 14:00 GMT+02:00 Michael Biebl :
>> > 2016-07-18 13:54 GMT+02:00 Lennart Poettering :
>> >> On Mon, 18.07.16 13:37, Michael Biebl (mbi...@gmail.com) wrote:
>> >>
>> >>> 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.


>> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Lennart Poettering]

On Mon, 18.07.16 14:51, Michael Biebl (mbi...@gmail.com) wrote:

> 2016-07-18 14:46 GMT+02:00 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.
> >
> > Note that this is even documented here since a long time:
> >
> > 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Lennart Poettering]

On Mon, 18.07.16 14:41, Michael Biebl (mbi...@gmail.com) wrote:

> 2016-07-18 14:00 GMT+02:00 Michael Biebl :
> > 2016-07-18 13:54 GMT+02:00 Lennart Poettering :
> >> On Mon, 18.07.16 13:37, Michael Biebl (mbi...@gmail.com) wrote:
> >>
> >>> 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...

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Michael Biebl]

2016-07-18 14:00 GMT+02:00 Michael Biebl :
> 2016-07-18 13:54 GMT+02:00 Lennart Poettering :
>> On Mon, 18.07.16 13:37, Michael Biebl (mbi...@gmail.com) wrote:
>>
>>> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Michael Biebl]

2016-07-18 13:54 GMT+02:00 Lennart Poettering :
> On Mon, 18.07.16 13:37, Michael Biebl (mbi...@gmail.com) wrote:
>
>> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Lennart Poettering]

On Mon, 18.07.16 13:37, Michael Biebl (mbi...@gmail.com) wrote:

> 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
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[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

2016-07-18 12:36 GMT+02:00 Lennart Poettering :
> On Sat, 16.07.16 17:22, Christian Hofstaedtler (c...@zeha.at) wrote:
>
>> 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
> systemd-devel@lists.freedesktop.org
> 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?
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel

Re: [systemd-devel] sigpwr.target - intended usage?

[Lennart Poettering]

On Sat, 16.07.16 17:22, Christian Hofstaedtler (c...@zeha.at) wrote:

> 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
systemd-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/systemd-devel