shutdown code for UPS

I’m working on a UPS monitor and need to set SIGPWR on all threads running.

kill(1, SIGPWR);

seems like a logical start and is usable for some UNIX variants, but does not seem to do anything on the RTP (although I have not tested it except to note that the equivalant shell command does nothing that I can tell to a running system).

sysmgr_reboot();

causes an instant reboot. Is the source the shutdown around for looking
at?

thanks,
Dave


David L. Hawley D.L. Hawley and Associates

The sysmgr_reboot() will invoke ‘reboot’ callout from startup. There is
source for it (on QNX4 hosted system).

There are other ways to reboot, for example writing 2 particular values into
2 particular ports on intel chipsets will reset CPU and PCI bus. I can look
up if you want.

As for making ‘graceful’ shutdown you’re bound to read /proc filesystem,
figure out who filesystem managers are and terminate them. Have code for
that too.

  • igor

“David Hawley” <David.L.Hawley@computer.org> wrote in message
news:Voyager.010104224817.602150A@shadow…

I’m working on a UPS monitor and need to set SIGPWR on all threads
running.

kill(1, SIGPWR);

seems like a logical start and is usable for some UNIX variants, but does
not seem to do anything on the RTP (although I have not tested it except to

note that the equivalant shell command does nothing that I can tell to a
running system).

sysmgr_reboot();

causes an instant reboot. Is the source the shutdown around for looking
at?

thanks,
Dave


David L. Hawley D.L. Hawley and Associates

Previously, Igor Kovalenko wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just terminate the file managers. I would have hoped that they would do the right thing if hit with SIGPWR though - that seems to be what happens with QNX4.

Actually, it seems that all threads need to see SIGPWR - they may need to prepare for shutdown in different ways. Is there no way to do that?

The sysmgr_reboot() will invoke ‘reboot’ callout from startup.There is
source for it (on QNX4 hosted system).

There are other ways to reboot, for example writing 2
particular values into
2 particular ports on intel chipsets will reset CPU and PCI bus.
I can look up if you want.

As for making ‘graceful’ shutdown you’re bound to read /proc
filesystem, figure out who filesystem managers are and terminate
them. Have code for that too.

  • igor

“David Hawley” <> David.L.Hawley@computer.org> > wrote in message
news:Voyager.010104224817.602150A@shadow…
I’m working on a UPS monitor and need to set SIGPWR on all threads
running.

kill(1, SIGPWR);

seems like a logical start and is usable for some UNIX variants, but does
not seem to do anything on the RTP (although I have not tested it except to
note that the equivalant shell command does nothing that I can tell to a
running system).

sysmgr_reboot();

causes an instant reboot. Is the source the shutdown around for looking
at?

thanks,
Dave


David L. Hawley D.L. Hawley and Associates

\


David L. Hawley D.L. Hawley and Associates

Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.


Mitchell Schoenbrun --------- maschoen@pobox.com

Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:

Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

In my code I use: system(“shutdown -f”); with no problems.

KenR

David Hawley wrote:

Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:
Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

David Hawley <David.L.Hawley@computer.org> wrote:

Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:
Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

Well if you don’t mind a little work, one way you could deal with it
is to readdir() /proc/mount to get a list of pids of programs that have
something mounted into the namespace(should cover all your file systems).
Then you could walk through proc, find all the pids in the system and
anything that was not in your mount list above, you could drop a SIGPWR/
SIGINT on and then once they are all gone, drop a SIGPWR on all the
mount pids, and that may be enough to get all the apps down happily, and
get you to a state where poweroff is safe.

-Peter

Sorry to intrude but I need to jump in and ask this question:
Except for my applications doesn’t system(“shutdown -f”) cause the OS to stop cleanly? or am I naive? My applications can handle unclean shutdowns so I only care about the OS being healthy on re-start.

I understand David’s need but I want to understand if/where my approach may have a fault…

KenR

pgraves@qnx.com wrote:

David Hawley <> David.L.Hawley@computer.org> > wrote:
Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:
Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

Well if you don’t mind a little work, one way you could deal with it
is to readdir() /proc/mount to get a list of pids of programs that have
something mounted into the namespace(should cover all your file systems).
Then you could walk through proc, find all the pids in the system and
anything that was not in your mount list above, you could drop a SIGPWR/
SIGINT on and then once they are all gone, drop a SIGPWR on all the
mount pids, and that may be enough to get all the apps down happily, and
get you to a state where poweroff is safe.

-Peter

As far as I know that approach should work just fine, and stop
cleanly. And if you changed the call to system(shutdown -f &"); I
believe it would return and you could catch the SIGPWR it would drop
on your app, and you could clean it up as well if you wanted to.
I was just dropping another option in case he didn’t want to use
a system() call or have the extra binary on the target machine.
And if I am wrong on any of the above I am sure someone will correct
me…

-Peter

rectech <rectech@iname.com> wrote:

Sorry to intrude but I need to jump in and ask this question:
Except for my applications doesn’t system(“shutdown -f”) cause the OS to stop cleanly? or am I naive? My applications can handle unclean shutdowns so I only care about the OS being healthy on re-start.

I understand David’s need but I want to understand if/where my approach may have a fault…

KenR

pgraves@qnx.com > wrote:

David Hawley <> David.L.Hawley@computer.org> > wrote:
Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:
Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

Well if you don’t mind a little work, one way you could deal with it
is to readdir() /proc/mount to get a list of pids of programs that have
something mounted into the namespace(should cover all your file systems).
Then you could walk through proc, find all the pids in the system and
anything that was not in your mount list above, you could drop a SIGPWR/
SIGINT on and then once they are all gone, drop a SIGPWR on all the
mount pids, and that may be enough to get all the apps down happily, and
get you to a state where poweroff is safe.

-Peter

Previously, pgraves@qnx.com wrote in qdn.public.qnxrtp.os:

As far as I know that approach should work just fine, and stop
cleanly. And if you changed the call to system(shutdown -f &"); I
believe it would return and you could catch the SIGPWR it would drop
on your app, and you could clean it up as well if you wanted to.
I was just dropping another option in case he didn’t want to use
a system() call or have the extra binary on the target machine.
And if I am wrong on any of the above I am sure someone will correct
me…

The system( “shutdown &” ) option is what I’ll do for now. I also need
to shutdown the UPS. Why isn’t the shutdown source available? Another
wish is to get shutdown to turn off the CPU power supply, but I don’t
need that in this case.


-Peter

rectech <> rectech@iname.com> > wrote:
Sorry to intrude but I need to jump in and ask this question:
Except for my applications doesn’t system(“shutdown -f”) cause the OS to stop cleanly? or am I naive? My applications can handle unclean shutdowns so I only care about the OS being healthy on re-start.

I understand David’s need but I want to understand if/where my approach may have a fault…

KenR

pgraves@qnx.com > wrote:

David Hawley <> David.L.Hawley@computer.org> > wrote:
Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:
Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

Well if you don’t mind a little work, one way you could deal with it
is to readdir() /proc/mount to get a list of pids of programs that have
something mounted into the namespace(should cover all your file systems).
Then you could walk through proc, find all the pids in the system and
anything that was not in your mount list above, you could drop a SIGPWR/
SIGINT on and then once they are all gone, drop a SIGPWR on all the
mount pids, and that may be enough to get all the apps down happily, and
get you to a state where poweroff is safe.

-Peter


David L. Hawley D.L. Hawley and Associates

You could writes to a digital output to switch the AC power to the PC and UPS off. I don’t know if that helps…
KenR

David Hawley wrote:

Previously, > pgraves@qnx.com > wrote in qdn.public.qnxrtp.os:
As far as I know that approach should work just fine, and stop
cleanly. And if you changed the call to system(shutdown -f &"); I
believe it would return and you could catch the SIGPWR it would drop
on your app, and you could clean it up as well if you wanted to.
I was just dropping another option in case he didn’t want to use
a system() call or have the extra binary on the target machine.
And if I am wrong on any of the above I am sure someone will correct
me…


The system( “shutdown &” ) option is what I’ll do for now. I also need
to shutdown the UPS. Why isn’t the shutdown source available? Another
wish is to get shutdown to turn off the CPU power supply, but I don’t
need that in this case.

-Peter

rectech <> rectech@iname.com> > wrote:
Sorry to intrude but I need to jump in and ask this question:
Except for my applications doesn’t system(“shutdown -f”) cause the OS to stop cleanly? or am I naive? My applications can handle unclean shutdowns so I only care about the OS being healthy on re-start.

I understand David’s need but I want to understand if/where my approach may have a fault…

KenR

pgraves@qnx.com > wrote:

David Hawley <> David.L.Hawley@computer.org> > wrote:
Previously, Mitchell Schoenbrun wrote in qdn.public.qnxrtp.os:
Previously, David Hawley wrote in qdn.public.qnxrtp.os:

I guess that I don’t really need to shutdown/reboot, just
terminate the file managers. I would have hoped that they
would do the right thing if hit with SIGPWR though - that
seems to be what happens with QNX4.

While this is a quite debatable issue, I think it makes more
sense to give the application control. That way they can at
least attempt to clean things up in a respectable manner.
With the file system process gone, this would be no longer
possible.

I agree with you. I don’t want to terminate the file managers for the reason that you indicate. In fact I’m not sure why I wrote the above.

what I’d like to see is how to set SIGPWR on all threads so that apps could respond as needed. In the meantime, I’d hope that the file managers would keep responding and at the same time try to flush caches.

Looks like my best bet since nobody is coming up with the code for shutdown, is to spawn it myself.


David L. Hawley D.L. Hawley and Associates

Well if you don’t mind a little work, one way you could deal with it
is to readdir() /proc/mount to get a list of pids of programs that have
something mounted into the namespace(should cover all your file systems).
Then you could walk through proc, find all the pids in the system and
anything that was not in your mount list above, you could drop a SIGPWR/
SIGINT on and then once they are all gone, drop a SIGPWR on all the
mount pids, and that may be enough to get all the apps down happily, and
get you to a state where poweroff is safe.

-Peter


\

David L. Hawley D.L. Hawley and Associates

Previously, rectech wrote in qdn.public.qnxrtp.os:

You could writes to a digital output to switch the AC power to the
PC and UPS off. I don’t know if that helps…

This is not necessary - the UPS will shut off if you pull RTS high
on most USP’s. One other I have should shutdown if sent a break if
I’m reading the circuit correctly.


David L. Hawley D.L. Hawley and Associates