SIGPWR not handled by init?

NAVIGATION

CATEGORIES

REFERRENCE

If you have some good idea, Cilck and mail to us please...

LINKS

Home » BSD

SIGPWR not handled by init?
7 answers - 518 bytes -
I noticed that init on NetBSD doesn't seem to handle SIGPWR reasonably.
This is unfortunate, because init could be used to initiate a "safe"
shutdown, switching run-states, etc.
I know there is powerd that can watch for power button events, but we
also want to deal with the case like critically low battery power, etc.
In some of these cases we'd rather have init shutdown gracefully than
just do a hard shutdown.
Thoughts? (include me in replies, as I'm not on tech-kern@)
No.1 | | 609 bytes | |
Thu, Jul 06, 2006 at 02:52:53PM -0700, Garrett D'Amore wrote:
I noticed that init on NetBSD doesn't seem to handle SIGPWR reasonably.
This is unfortunate, because init could be used to initiate a "safe"
shutdown, switching run-states, etc.

Yes, and the apropriate powerd script can tell it to do so.

We had a lengthy discussion about this at least once, years ago, and back
then consensus was to have powerd and it's scripts to be the sole userland
part responsible for this things.

I don't see what SIGPWR -init would gain us.

Martin
No.2 | | 1607 bytes | |
Martin Husemann wrote:
Thu, Jul 06, 2006 at 02:52:53PM -0700, Garrett D'Amore wrote:

>I noticed that init on NetBSD doesn't seem to handle SIGPWR reasonably.
>This is unfortunate, because init could be used to initiate a "safe"
>shutdown, switching run-states, etc.
>
>
Yes, and the apropriate powerd script can tell it to do so.

We had a lengthy discussion about this at least once, years ago, and back
then consensus was to have powerd and it's scripts to be the sole userland
part responsible for this things.

I don't see what SIGPWR -init would gain us.

Martin

Two things:

1) init is _always_ running. so as a fallback when powerd isn't around,
at least init could do something sane

2) any root or kernel thread can easily find and kill -PWR 1. For
powerd to work as well, we would have to add some accessible interface
for userland programs (perhaps just having powerd do the SIGPWR thing,
though then you also have to find the pid for powerd) and it means that
kernel code (right now anyway) has to set up sysmon events for this,
which is a lot more effort than just sending SIGPWR to process 1.

AFAIK, right now powerd doesn't even handle this condition (low power)
at all. It only deals with power button and lidswitch events. So I was
trying to figure out what the correct action would be for me to do when
my power controller is telling it is time to shut down if I care about
my data.

Anyway, just wondering.
No.3 | | 789 bytes | |
# Garrett D'Amore 2006-07-06:
I know there is powerd that can watch for power button events, but we
also want to deal with the case like critically low battery power, etc.

and powerd should be tought about them ;-) (one way or the other,
see smb's recent comments at tech-kern)

In some of these cases we'd rather have init shutdown gracefully than
just do a hard shutdown.

What would hardcoded SIGPWR action in init(8) gain us, compared to
any-action-we-might-want run from powerd script? If it's just latency
issue, the user needs to raise critical capacity (or whatever) treshold
on the battery.

I really don't think signals are the best way to propagate this kind
of system conditions
-- Jachym
No.4 | | 505 bytes | |
Jul 6, 2006, at 2:52 PM, Garrett D'Amore wrote:

I know there is powerd that can watch for power button events, but we
also want to deal with the case like critically low battery power,
etc.
In some of these cases we'd rather have init shutdown gracefully than
just do a hard shutdown.

powerd(8) can do that, too create a new event type and the
script powerd runs can do whatever you want (like "showdown -p now"
after logging a message).
-- thorpej
No.5 | | 1266 bytes | |
Thu, Jul 06, 2006 at 02:52:53PM -0700, Garrett D'Amore wrote:
I noticed that init on NetBSD doesn't seem to handle SIGPWR reasonably.
This is unfortunate, because init could be used to initiate a "safe"
shutdown, switching run-states, etc.

I know there is powerd that can watch for power button events, but we
also want to deal with the case like critically low battery power, etc.
In some of these cases we'd rather have init shutdown gracefully than
just do a hard shutdown.

Thoughts? (include me in replies, as I'm not on tech-kern@)

Well, a few weeks back I had thoughts of a uhidups(4) that talked
to powerd. But, that wouldn't support contact-closure UPSes, and
the HID UPSes have lots of quirks. This came about because I (at
the time) thought the
userland dance before the suicide was a tad crazy. So (although
this still requires the aforementioned dance), perhaps, there should be
a way for other userland hw-monitoring daemons to talk to powerd?
Just a thought, NUT's upsmon works almost as well as it can already.

Jonathan Kollasch

PGP SIGNATURE
Version: GnuPG v1.4.2 (NetBSD)

NZqdiMHaneSXacBDzX+MIs=
=TlCX
PGP SIGNATURE
No.6 | | 285 bytes | |
Fri, Jul 07, 2006 at 02:43:22AM -0500, Jonathan A. Kollasch wrote:
there should be
a way for other userland hw-monitoring daemons to talk to powerd?
Yes, we need a way to insert events from userland, either into sysmon
or directly into powerd.
Martin
No.7 | | 336 bytes | |
Jul 7, 2006, at 9:02 AM, Jason Thorpe wrote:

Yes, I think a way for other privileged userland processes to talk
to powerd would be appropriate.

and let me further clarify that I think the best way to do this
would be to have a way to inject events into sysmon (as others have
mentioned).
-- thorpej

Re: SIGPWR not handled by init?

EMSDN.COM

Archive for 'SIGPWR not handled by init?' by Garrett DAmore

BSD

SIGPWR not handled by init?