SIGPWR not delivered on shutdown?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
1

“shutdown” utility manual says SIGPWR is delivered to
each process on shutdown, but plain simple program below
seems not to receive it.
(run & kill -PWR from console works, as expected)

Is it that only resource managers get SIGPWR delivered?

kabe

#include <stdio.h>
#include <signal.h>

int gSigpwr_count = 0;

void
handle_sigpwr(int sig)
{
gSigpwr_count++;
}

int
main()
{
signal(SIGPWR, handle_sigpwr);
fprintf(stderr, “Pid %d Waiting for signal…\n”, getpid());
sigpause(0);
fprintf(stderr, “count=%d\n”, gSigpwr_count);
{FILE *f=fopen("./got_sigpwr", “w”); fprintf(f,“count=%d\n”, gSigpwr_count); fclose(f);}
return 0;
}

2

In the documentation for shutdown says that SIGPWR is sent to each process
listed under /proc.

Regards,
Dave B.


<kabe@sra-tohoku.co.jp> wrote in message news:ahm4p6$8qo$1@inn.qnx.com…

“shutdown” utility manual says SIGPWR is delivered to
each process on shutdown, but plain simple program below
seems not to receive it.
(run & kill -PWR from console works, as expected)

Is it that only resource managers get SIGPWR delivered?

kabe

#include <stdio.h
#include <signal.h

int gSigpwr_count = 0;

void
handle_sigpwr(int sig)
{
gSigpwr_count++;
}

int
main()
{
signal(SIGPWR, handle_sigpwr);
fprintf(stderr, “Pid %d Waiting for signal…\n”, getpid());
sigpause(0);
fprintf(stderr, “count=%d\n”, gSigpwr_count);
{FILE *f=fopen("./got_sigpwr", “w”); fprintf(f,“count=%d\n”,
gSigpwr_count); fclose(f);}
return 0;
}

3

One problem I might see with your code is that, you are trying
to store information on the disk. Problem is, devb-eide might be
getting the signal first.

You might try to change the priority of your process to exceed
the priority of any other process. When you receive the signal
you might want to try manually toggling a line on a serial or
parallel port to ensure that you can reliably get any output
from you program.

I have also noticed that QNX4 was a lot gentler shutting the
system down.

With both 6.1a and 6.2 we have noticed here that the clean bit
in the file system never seems to get set at shutdown. Which of
course makes our start ups longer, as we have to do a chkfsys at
boot time.

kabe@sra-tohoku.co.jp wrote:

“shutdown” utility manual says SIGPWR is delivered to
each process on shutdown, but plain simple program below
seems not to receive it.
(run & kill -PWR from console works, as expected)

Is it that only resource managers get SIGPWR delivered?

kabe

#include <stdio.h
#include <signal.h

int gSigpwr_count = 0;

void
handle_sigpwr(int sig)
{
gSigpwr_count++;
}

int
main()
{
signal(SIGPWR, handle_sigpwr);
fprintf(stderr, “Pid %d Waiting for signal…\n”, getpid());
sigpause(0);
fprintf(stderr, “count=%d\n”, gSigpwr_count);
{FILE *f=fopen("./got_sigpwr", “w”); fprintf(f,“count=%d\n”, gSigpwr_count); fclose(f);}
return 0;
}

regards,
Tom

4

In the documentation for shutdown says that SIGPWR is sent to each process
listed under /proc.

Every running process is registered as /proc/.

Just in case I stuffed the test prog in /proc/boot by rebuilding ifs;
no banana.

One problem I might see with your code is that, you are trying
to store information on the disk. Problem is, devb-eide might be
getting the signal first.

So I’m using the stderr for diag.
I don’t think “shutdown” is hammering VGA directly for diag output
after killing devc-con rightaway.
Also, “shutdown” kills devb-eide in last order, so disk write did work.


After trying somethings, not SIGPWR but hooking SIGTERM works;
I dunno if this is a bug or not.
Sending SIGTERM (in addition to SIGPWR?) seems reasonable enough tho.

kabe

#include <stdio.h>
#include <signal.h>

int gSigpwr_count = 0;
int gSigterm_count = 0;

void
handle_sigpwr(int sig)
{
gSigpwr_count++;
}

void
handle_sigterm(int sig)
{
gSigterm_count++;
}

int
main()
{
pid_t mypid = getpid();
signal(SIGPWR, handle_sigpwr);
signal(SIGTERM, handle_sigterm);
fprintf(stderr, “Pid %d (0x%x) Waiting for signal…\n”, mypid, mypid);
sigpause(0);
fprintf(stderr, “Pid %d (0x%x) pwr=%d, term=%d\n”, mypid, mypid, gSigpwr_count, gSigterm_count);
{FILE *f=fopen("./got_sigpwr", “w”); fprintf(f,“pwr=%d term=%d\n”, gSigpwr_count, gSigterm_count); fclose(f);}
return 0;
}

5

There is already a PR assigned to this issue. It’s a doc bug, processes are
hit with a SIGTERM, and anyone hanging around gets a SIGKILL for their
troubles. QNX4 used to hit everyone with a SIGPWR first…

–
Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>
<kabe@sra-tohoku.co.jp> wrote in message news:ahm4p6$8qo$1@inn.qnx.com…

“shutdown” utility manual says SIGPWR is delivered to
each process on shutdown, but plain simple program below
seems not to receive it.
(run & kill -PWR from console works, as expected)

Is it that only resource managers get SIGPWR delivered?

kabe

#include <stdio.h
#include <signal.h

int gSigpwr_count = 0;

void
handle_sigpwr(int sig)
{
gSigpwr_count++;
}

int
main()
{
signal(SIGPWR, handle_sigpwr);
fprintf(stderr, “Pid %d Waiting for signal…\n”, getpid());
sigpause(0);
fprintf(stderr, “count=%d\n”, gSigpwr_count);
{FILE *f=fopen("./got_sigpwr", “w”); fprintf(f,“count=%d\n”,
gSigpwr_count); fclose(f);}
return 0;
}

6

I’m unclear. Are you saying that SIGPWR is NOT the correct signal to give
processes to let them know that you’re shutting down?

“Adam Mallory” <amalloryNOSPAM@NOSPAMqnx.com> wrote in message
news:ahs3ka$lrs$1@nntp.qnx.com…

There is already a PR assigned to this issue. It’s a doc bug, processes
are
hit with a SIGTERM, and anyone hanging around gets a SIGKILL for their
troubles. QNX4 used to hit everyone with a SIGPWR first…

–
Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
kabe@sra-tohoku.co.jp> > wrote in message news:ahm4p6$8qo$> 1@inn.qnx.com> …
“shutdown” utility manual says SIGPWR is delivered to
each process on shutdown, but plain simple program below
seems not to receive it.
(run & kill -PWR from console works, as expected)

Is it that only resource managers get SIGPWR delivered?

kabe

#include <stdio.h
#include <signal.h

int gSigpwr_count = 0;

void
handle_sigpwr(int sig)
{
gSigpwr_count++;
}

int
main()
{
signal(SIGPWR, handle_sigpwr);
fprintf(stderr, “Pid %d Waiting for signal…\n”, getpid());
sigpause(0);
fprintf(stderr, “count=%d\n”, gSigpwr_count);
{FILE *f=fopen("./got_sigpwr", “w”); fprintf(f,“count=%d\n”,
gSigpwr_count); fclose(f);}
return 0;
}

7

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

I’m unclear. Are you saying that SIGPWR is NOT the correct signal to give
processes to let them know that you’re shutting down?

Sounds like someone (foolishly) decided that SIGTERM was more appropriate.
I don’t agree… I think SIGPWR makes much more sense.

Cheers,
Camz.

“Adam Mallory” <> amalloryNOSPAM@NOSPAMqnx.com> > wrote in message
news:ahs3ka$lrs$> 1@nntp.qnx.com> …
There is already a PR assigned to this issue. It’s a doc bug, processes
are
hit with a SIGTERM, and anyone hanging around gets a SIGKILL for their
troubles. QNX4 used to hit everyone with a SIGPWR first…

8

<camz@passageway.com> wrote in message news:ahsjgj$5p3$2@inn.qnx.com…

“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I’m unclear. Are you saying that SIGPWR is NOT the correct signal to
give
processes to let them know that you’re shutting down?

Sounds like someone (foolishly) decided that SIGTERM was more appropriate.
I don’t agree… I think SIGPWR makes much more sense.

Cheers,
Camz.

Absolutely. That was my point.

9

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

I’m unclear. Are you saying that SIGPWR is NOT the correct signal to give
processes to let them know that you’re shutting down?

No, I’m saying that the shutdown utility doesn’t issue the SIGPWR as per the
original posting.

<camz@passageway.com> wrote:

Sounds like someone (foolishly) decided that SIGTERM was more appropriate.
I don’t agree… I think SIGPWR makes much more sense.

SIGTERM is more than applicable, it’s meant to be a process termination
signal (we use it to warn processes they should be coming down). SIGKILL
(used to wack anyone still hanging around after some time) is the heavy
handed approach used when needed at the end. SIGPWR, on the other hand, is
for either some type of power failure/notification problem (ie. UPS
signalling that it’s now on reserve power), not the fact that a controlled
reset or shutdown is going to occur. SIGPWR doesn’t mean that a process
should terminate - it’s an indication that power might be in short supply,
save what you need. I think overloading this signal to also mean that
someone is shutting down the system (via. shutdown command) is wrong.

But if you really want to, you can just as easily write your own customized
shutdown util to do exactly what you want it to, SIGPWR and all.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

10

SIGPWR doesn’t mean that a process
should terminate - it’s an indication that power might be in short supply,
save what you need. I think overloading this signal to also mean that
someone is shutting down the system (via. shutdown command) is wrong.

I agree that this is the standard (POSIX?) view. If your process gets a
SIGTERM it should shut down cleanly - why does the reason for the SIGTERM
make a difference?

But it is also true that QNX4 took a different view and used SIGPWR in a
non-standard (but arguably more useful) fashion.

It would be helpful to those migrating from QNX4 if the docs explained this.

Rob Rutherford

11

Robert Rutherford <ruzz@nospamplease.ruzz.com> wrote:
:> SIGPWR doesn’t mean that a process
:> should terminate - it’s an indication that power might be in short supply,
:> save what you need. I think overloading this signal to also mean that
:> someone is shutting down the system (via. shutdown command) is wrong.

: I agree that this is the standard (POSIX?) view. If your process gets a
: SIGTERM it should shut down cleanly - why does the reason for the SIGTERM
: make a difference?

: But it is also true that QNX4 took a different view and used SIGPWR in a
: non-standard (but arguably more useful) fashion.

: It would be helpful to those migrating from QNX4 if the docs explained this.

I’ll pass this on. Thanks for the suggestion.

Steve Reid stever@qnx.com
TechPubs (Technical Publications)
QNX Software Systems

12

“Robert Rutherford” <ruzz@NoSpamPlease.ruzz.com> wrote in message
news:ai4p2q$2ao$1@inn.qnx.com…

I agree that this is the standard (POSIX?) view. If your process gets a
SIGTERM it should shut down cleanly - why does the reason for the SIGTERM
make a difference?

It only makes a difference when comparing the use of SIGPWR vs SIGTERM.
Using SIGTERM for exactly what it’s for, allows SIGPWR to be used by the
user w/o contention or ambiguity.

But it is also true that QNX4 took a different view and used SIGPWR in a
non-standard (but arguably more useful) fashion.

QNX4 did many things differently (good and bad), and if someone wanted the
same functionality, it would be trivial to add to shutdown, or you could
simply write your own shutdown util/script. Just walk the /proc tree for
the pids, hitting them with SIGPWR, then SIGKILL (except yourself :slight_smile: ) and
reboot/shutdown your board. Lather, rinse, repeat ™ :slight_smile:

It would be helpful to those migrating from QNX4 if the docs explained
this.

As I mentioned earlier, this was marked as a Doc PR.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

13

I disagree. SIGTERM does not tell the process WHY it is being terminated.
It doesn’t tell the process that EVERY process is being terminated.

The only difference between a UPS failing and flipping the power switch is
that one is deliberate. But in both cases I believe that most processes
will want to handle themselves the same.

You’re right SIGKILL is very wrong.

Then there should be an command line option to shutdown to let the user
decide if they wish to deliver the correct signal or not.

For the record, this whole argument only applies to software that you didn’t
write. In all of my applications I have graceful messages that say “You
need to shut down now”. To which the application replies when it is ready
“OK. I’m ready”. And applications can be shutdown in an appropriate order.


“Adam Mallory” <amalloryNOSPAM@NOSPAMqnx.com> wrote in message
news:ai46k7$k03$1@nntp.qnx.com…

“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I’m unclear. Are you saying that SIGPWR is NOT the correct signal to
give
processes to let them know that you’re shutting down?

No, I’m saying that the shutdown utility doesn’t issue the SIGPWR as per
the
original posting.

camz@passageway.com> > wrote:
Sounds like someone (foolishly) decided that SIGTERM was more
appropriate.
I don’t agree… I think SIGPWR makes much more sense.

SIGTERM is more than applicable, it’s meant to be a process termination
signal (we use it to warn processes they should be coming down). SIGKILL
(used to wack anyone still hanging around after some time) is the heavy
handed approach used when needed at the end. SIGPWR, on the other hand,
is
for either some type of power failure/notification problem (ie. UPS
signalling that it’s now on reserve power), not the fact that a controlled
reset or shutdown is going to occur. SIGPWR doesn’t mean that a process
should terminate - it’s an indication that power might be in short supply,
save what you need. I think overloading this signal to also mean that
someone is shutting down the system (via. shutdown command) is wrong.

But if you really want to, you can just as easily write your own
customized
shutdown util to do exactly what you want it to, SIGPWR and all.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net

14

“Bill Caroselli (Q-TPS)” <QTPS@earthlink.net> wrote:

I disagree. SIGTERM does not tell the process WHY it is being terminated.
It doesn’t tell the process that EVERY process is being terminated.

Exactly. This is why I think the QNX4 behaviour was correct.

The only difference between a UPS failing and flipping the power switch is
that one is deliberate. But in both cases I believe that most processes
will want to handle themselves the same.

Exactly. I agree 100%. There is a difference between asking a single
process to terminate and asking them ALL to terminate. The filesystems
are a good example. If I am shutting down the filesystems (perhaps to
restart a newer version of them from /dev/shmem) than I want them to flush
to disk and die. If the power is going off, then I want them to flush to
disk and stick around so that dying apps can save state (I’d also want them
to direct all subsequent writes to disk immediately).

Bill is correct though, the only difference between a UPS initiating an
orderly shutdown and actually running the shutdown command is the amount
of time you have. With shutdown it is 1 second or 10 seconds, with a UPS
it is probably much longer.

In all honesty, most UPS software DOESNOT* notify every app when it goes
onto battery power. It only notifies them when it determines that it will
not be able to run any longer and has to perform an orderly shutdown. In
this case… SIGPWR would be used in EXACTLY the same context as how we
use the shutdown command.

Then there should be an command line option to shutdown to let the user
decide if they wish to deliver the correct signal or not.

That would work. It is rediculous to tell us to write our own app for what
is a common proceedure. While I am at it, I should also rant that we should
have ctrl-alt-shift-del too.

Cheers,
Camz.

15

Of course a graceful way anyone could do this is to write their own shutdown
script that issues ‘slay -sSIGwhatever -fQ my_app’ for each of their own
applications and then issue a ‘shutdown’ for the rest of the OS. For me, it
is important that my apps shutdown BEFORE the filesystem, etc.

“Bill Caroselli (Q-TPS)” <QTPS@EarthLink.net> wrote in message
news:ai6l18$f8m$1@inn.qnx.com…

I disagree. SIGTERM does not tell the process WHY it is being terminated.
It doesn’t tell the process that EVERY process is being terminated.

The only difference between a UPS failing and flipping the power switch is
that one is deliberate. But in both cases I believe that most processes
will want to handle themselves the same.

You’re right SIGKILL is very wrong.

Then there should be an command line option to shutdown to let the user
decide if they wish to deliver the correct signal or not.

For the record, this whole argument only applies to software that you
didn’t
write. In all of my applications I have graceful messages that say “You
need to shut down now”. To which the application replies when it is ready
“OK. I’m ready”. And applications can be shutdown in an appropriate
order.


“Adam Mallory” <> amalloryNOSPAM@NOSPAMqnx.com> > wrote in message
news:ai46k7$k03$> 1@nntp.qnx.com> …
“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I’m unclear. Are you saying that SIGPWR is NOT the correct signal to
give
processes to let them know that you’re shutting down?

No, I’m saying that the shutdown utility doesn’t issue the SIGPWR as per
the
original posting.

camz@passageway.com> > wrote:
Sounds like someone (foolishly) decided that SIGTERM was more
appropriate.
I don’t agree… I think SIGPWR makes much more sense.

SIGTERM is more than applicable, it’s meant to be a process termination
signal (we use it to warn processes they should be coming down).
SIGKILL
(used to wack anyone still hanging around after some time) is the heavy
handed approach used when needed at the end. SIGPWR, on the other hand,
is
for either some type of power failure/notification problem (ie. UPS
signalling that it’s now on reserve power), not the fact that a
controlled
reset or shutdown is going to occur. SIGPWR doesn’t mean that a process
should terminate - it’s an indication that power might be in short
supply,
save what you need. I think overloading this signal to also mean that
someone is shutting down the system (via. shutdown command) is wrong.

But if you really want to, you can just as easily write your own
customized
shutdown util to do exactly what you want it to, SIGPWR and all.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ > amallory@qnx.com > ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <> pschon@baste.magibox.net
\

16

<camz@passageway.com> wrote in message news:ai6ltu$fni$1@inn.qnx.com…

“Bill Caroselli (Q-TPS)” <> QTPS@earthlink.net> > wrote:
I disagree. SIGTERM does not tell the process WHY it is being
terminated.
It doesn’t tell the process that EVERY process is being terminated.

Exactly. This is why I think the QNX4 behaviour was correct.

This logic applies to SIGPWR also - the signal doesn’t tell you what type of
power failure is causing it (UPS, power flip etc), nor does it tell you that
every process is being terminated - in fact SIGPWR says nothing about
termination.

The only difference between a UPS failing and flipping the power switch
is
that one is deliberate. But in both cases I believe that most processes
will want to handle themselves the same.

Exactly. I agree 100%. There is a difference between asking a single
process to terminate and asking them ALL to terminate. The filesystems
are a good example. If I am shutting down the filesystems (perhaps to
restart a newer version of them from /dev/shmem) than I want them to flush
to disk and die. If the power is going off, then I want them to flush to
disk and stick around so that dying apps can save state (I’d also want
them
to direct all subsequent writes to disk immediately).

You’re debating the results of the signal which is process specific. I’m
saying that SIGPWR shouldn’t be used to tell a process to terminate nice and
clean. SIGTERM is for orderly termination, SIGKILL is for the heavy handed
approach. SIGPWR is a notification of a power related nature - the fact
that most applications will terminate nicely isn’t relevant, since some
applications will not (for good reason).

Bill is correct though, the only difference between a UPS initiating an
orderly shutdown and actually running the shutdown command is the amount
of time you have. With shutdown it is 1 second or 10 seconds, with a UPS
it is probably much longer.

These are two seperate problems - if the UPS goes on reserve power, the last
thing you want to do is shut down everything. You’d want to tell any
applications with power consuming devices associated with them to shutdown,
and conserve your power. Only after the reserve is depleated to a certain
threshold would you want to initiate a full system shutdown. So there is a
world of different between the shutdown command and a UPS (and associated
driver which sends the SIGPWR to the processes).

In all honesty, most UPS software DOESNOT* notify every app when it goes
onto battery power. It only notifies them when it determines that it will
not be able to run any longer and has to perform an orderly shutdown. In
this case… SIGPWR would be used in EXACTLY the same context as how we
use the shutdown command.

Most software will indicate many changes in UPS status - from
voltage/current changes to battery level. If UPS software wants to trigger
a orderly shutdown, it sends a SIGTERM. Since SIGPWR should have already
been sent to processes indicating that we’re on reserve power, you can infer
that a SIGTERM while on reserve power is a termination request for power
level reasons.

Then there should be an command line option to shutdown to let the user
decide if they wish to deliver the correct signal or not.

That would work. It is rediculous to tell us to write our own app for
what
is a common proceedure. While I am at it, I should also rant that we
should
have ctrl-alt-shift-del too.

This too was also mentioned in a previous post - I said that a command line
option to change the signal sent would be a trivial change.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>

17

In article <ai6lmc$fmi$1@inn.qnx.com>
QTPS@EarthLink.net writes:

Of course a graceful way anyone could do this is to write their own shutdown
script that issues ‘slay -sSIGwhatever -fQ my_app’ for each of their own
applications and then issue a ‘shutdown’ for the rest of the OS. For me, it
is important that my apps shutdown BEFORE the filesystem, etc.

Hence a need for /etc/rc.d/rc.shutdown
which isn’t provided now.

It’s a userland issue, so “make your own shutdown proggie” seems a
boilerplate answer, but if QNX supplied a standard shutdown hook
(rc.shutdown), lot of people will be using it without fuss. Big Win


And current “shutdown” just doesn’t seem to fire off SIGTERM;
it tries to kill devb-* last, which isn’t a trivial behavior
to recreate on your own shutdown proggie.

kabe

18

Adam Mallory <amalloryNOSPAM@nospamqnx.com> wrote:

This logic applies to SIGPWR also - the signal doesn’t tell you what type of
power failure is causing it (UPS, power flip etc), nor does it tell you that
every process is being terminated - in fact SIGPWR says nothing about
termination.

If power is going away, it really doesn’t matter WHY. If power is going away
then all processes will die, there is no other option once the power is gone.

What we are saying is that SIGPWR tells an app that the system is going down
RSN. It does not tell the app what the value of NOW is (ie. 10 seconds, 20
minutes, etc.)

You’re debating the results of the signal which is process specific. I’m
saying that SIGPWR shouldn’t be used to tell a process to terminate nice and
clean.

Neither are we.
We are saying that if a shutdown hits processes with SIGTERM, that it’s not
the same as hitting them with SIGPWR. If you hit them with SIGPWR then the
app can decide what to do, with SIGTERM it can’t really do that (short of
perhaps a clean termination).

This is why we want SIGPWR to be generated by the shutdown command, and not
SIGTERM. We want to be able to code apps that respond appropriately to the
impending death of the system (due to power loss) rather than just being asked
to terminate.

These are two seperate problems - if the UPS goes on reserve power, the last
thing you want to do is shut down everything. You’d want to tell any

I never said that the UPS monitoring software would generate SIGPWR when
it went on reserve power. I only said that it might choose to. The point
is that SIGPWR would not neccisarily terminate all apps, but SIGTERM would.

threshold would you want to initiate a full system shutdown. So there is a
world of different between the shutdown command and a UPS (and associated
driver which sends the SIGPWR to the processes).

What UPS software does while on reserve power, yes. What it does when it
determines that it must power down the system is different. In that case it
would simply invoke the shutdown mechanism in the system (and that would send
SIGPWR).

Most software will indicate many changes in UPS status - from
voltage/current changes to battery level. If UPS software wants to trigger
a orderly shutdown, it sends a SIGTERM. Since SIGPWR should have already
been sent to processes indicating that we’re on reserve power, you can infer
that a SIGTERM while on reserve power is a termination request for power
level reasons.

Geez, this is what we’ve been saying all along. SIGPWR lets an app make a
proper decision on what to do, and SIGTERM doesn not.

I disagree with you in that UPS software would have to generate SIGTERM.
If you look at most *nix systems, it’s way freaking more complicated than
that, and typically involves potentially complex shutdown scripts.
(i.e. files in /etc/init.d or /etc/rc.d all take a paramater that is one
of start, stop, or restart).

Lets use hockey as a better way to show what I think the two signals should
mean to an app.

SIGTERM - buzzer at the end of a period
SIGPWR - entering sudden death overtime

You will note that SIGPWR does not imply the end of the period explicitly,
although it does imply that it could happen any time.

This too was also mentioned in a previous post - I said that a command line
option to change the signal sent would be a trivial change.

I would vote for that as an end to this debate.

Cheers,
Camz.

19

kabe@sra-tohoku.co.jp wrote:

Hence a need for /etc/rc.d/rc.shutdown
which isn’t provided now.

It’s a userland issue, so “make your own shutdown proggie” seems a
boilerplate answer, but if QNX supplied a standard shutdown hook
(rc.shutdown), lot of people will be using it without fuss. Big Win

Actually, the whole rc.d/rc.local is a hack. It’s only on self-hosted
systems and IS NOT part of an embedded system. The only reaason the
rc.local script is run is because the QSS provided startup script actually
looks for it and invokes it at the end of its sequence.

This is why we need the behaviour of shutdown to send SIGPWR, so that apps
have their own hope in hell of actually knowin gwhat is going on as opposed
to just being terminated. (and then you could have an app that attempted
to execute rc.shutdown).

And current “shutdown” just doesn’t seem to fire off SIGTERM;
it tries to kill devb-* last, which isn’t a trivial behavior
to recreate on your own shutdown proggie.

It that is the behavior, than I agree, that is a bitch to make work properly.
If shutdown actually sent SIGPWR, there would be no need for such complexity.

You might be thinking of the photon shutdown util, and in that case it probably
should have it’s own script instead of a complex behaviour.
I recall that in QNX4, Photon would catch SIGPWR and actually display a nice
“shutting down” message briefly before dropping to text mode. A good example
of an app taking advantage of the difference between SIGPWR and SIGTERM.

Cheers,
Camz.

20

<camz@passageway.com> wrote in message news:aioulk$t6$1@inn.qnx.com…

If power is going away, it really doesn’t matter WHY. If power is going
away
then all processes will die, there is no other option once the power is
gone.

What we are saying is that SIGPWR tells an app that the system is going
down
RSN. It does not tell the app what the value of NOW is (ie. 10 seconds,
20
minutes, etc.)

You and I use SIGPWR for two different reasons. To me, SIGPWR means that
something power related just happened, not that power is going away. To you
SIGPWR means power is going away RSN, w/o exception.


Neither are we.
We are saying that if a shutdown hits processes with SIGTERM, that it’s
not
the same as hitting them with SIGPWR. If you hit them with SIGPWR then
the
app can decide what to do, with SIGTERM it can’t really do that (short of
perhaps a clean termination).

Of course the two are not the same, they mean different things. The
interpretation that SIGPWR implies a LOSS of power is incorrect - it
signals a power related event. I also don’t understand how an application
can’t do what it wants upon SIGTERM - you can do whatever you want,
including ignore it. SIGTERM is a request to shutdown, not a command -
SIGKILL is a command.

This is why we want SIGPWR to be generated by the shutdown command, and
not
SIGTERM. We want to be able to code apps that respond appropriately to
the
impending death of the system (due to power loss) rather than just being
asked
to terminate.

Than what you really want is a SIGPWR, followed by a SIGTERM. This way an
application can differentiate between a plain termination request, and a
“power related” terimination as well as a just plain power event, which
should not end in termination

I disagree with you in that UPS software would have to generate SIGTERM.
If you look at most *nix systems, it’s way freaking more complicated than
that, and typically involves potentially complex shutdown scripts.
(i.e. files in /etc/init.d or /etc/rc.d all take a paramater that is one
of start, stop, or restart).

Obviously power management is much more complicated, and involved - I never
said that SIGPWR was the end all/be all of power management. Blatantly
obvious statements are of no help in this discussion.

Lets use hockey as a better way to show what I think the two signals
should
mean to an app.

SIGTERM - buzzer at the end of a period
SIGPWR - entering sudden death overtime

You will note that SIGPWR does not imply the end of the period explicitly,
although it does imply that it could happen any time.

Seeing as the default behaviour in QNX4 for SIGPWR was to terminate, your
example doesn’t work in this case (and others).

In the end, QNX4 interpreted SIGPWR to mean “Power going down now or RSN”
and the default action was to terminate the process. This interpretation
which was incorrect and has been changed in Neutrino. SIGPWR no longer
terminates a process, as SIGPWR is an indication of a power event, not that
termination is required.

I would vote for that as an end to this debate.

Agreed.

\

Cheers,
Adam

QNX Software Systems Ltd.
[ amallory@qnx.com ]

With a PC, I always felt limited by the software available.
On Unix, I am limited only by my knowledge.
–Peter J. Schoenster <pschon@baste.magibox.net>