Let init know user wants to shutdown
Hi!
Init should get to know that user pressed power button (so it can do shutdown and poweroff). Plus, it is nice to let user know that we can read such event. [I hunted bug for few hours, thinking that kernel does not get the event at all].
Here's patch to do that. Please apply,
Pavel
drivers/acpi/events/evevent.c +6 -0
@@ -30,6 +30,8 @@#include "acnamesp.h" #include "accommon.h" +#include <linux/signal.h> +#define _COMPONENT EVENT_HANDLINGMODULE_NAME ("evevent" )
@@ -197,14 +172,18 @@if ((status_register &ACPI_STATUS_POWER_BUTTON ) && (enable_register &ACPI_ENABLE_POWER_BUTTON )) { +printk ("acpi: Power button pressed!\n" ); +kill_proc (1 ,SIGTERM ,1 ); int_status |=acpi_ev_fixed_event_dispatch (ACPI_EVENT_POWER_BUTTON ); } +/* sleep button event */ if ((status_register &ACPI_STATUS_SLEEP_BUTTON ) && (enable_register &ACPI_ENABLE_SLEEP_BUTTON )) { +printk ("acpi: Sleep button pressed!\n" ); int_status |=acpi_ev_fixed_event_dispatch (ACPI_EVENT_SLEEP_BUTTON ); }
Signature · 2 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [email protected]
In article <[email protected]>,
Quoted 8 lines · Pavel Machek
Hi!
Init should get to know that user pressed power button (so it can do shutdown and poweroff). Plus, it is nice to let user know that we can read such event. [I hunted bug for few hours, thinking that kernel does not get the event at all].
Here's patch to do that. Please apply,
Not so hasty ;)
drivers/acpi/events/evevent.c line 176
Quoted 2 lines
drivers/acpi/events/evevent.c +2
-0+printk ("acpi: Power button pressed!\n" ); +kill_proc (1 ,SIGTERM ,1 );
SIGTERM is a bad choise. Right now, init ignores SIGTERM. For good reason; on some (many?) systems, the shutdown scripts include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means "all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.
Perhaps SIGUSR1 ?
Mike.
In article <[email protected]>,
Quoted 8 lines · Miquel van Smoorenburg
SIGTERM is a bad choise. Right now, init ignores SIGTERM. For good reason; on some (many?) systems, the shutdown scripts include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means "all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.
Perhaps SIGUSR1 ?
In the immortal words of Max Headroom, t-t-talking to myself ;)
In fact, the kernel should probably use a real-time signal with si_code set to 1 for ctrl-alt-del, 2 for the powerbutton etc.
It should first check if process 1 (init) installed a handler for that real-time signal. If not, it should use the old signals (SIGINT for ctrl-alt-del, SIGWINCH for kbrequest).
Mike.
Quoted 6 lines · Miquel van Smoorenburg
the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means "all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.
-1 mean everything but init.
Quoted 1 line
From the manpage:
If pid equals -1, then sig is sent to every process except for the first one, from higher numbers in the process table to lower.
And later:
BUGS
It is impossible to send a signal to task number one, the init process, for which it has not installed a signal han-
dler. This is done to assure the system is not brought
down accidentally.
Kurt
Quoted 9 lines · Miquel van Smoorenburg
In article <[email protected]>,
Quoted 2 lines · Pavel Machek
Init should get to know that user pressed power button (so it can do shutdown and poweroff). Plus, it is nice to let user know that we can
Not so hasty ;)
drivers/acpi/events/evevent.c line 176
Quoted 2 lines
drivers/acpi/events/evevent.c +2
-0+printk ("acpi: Power button pressed!\n" ); +kill_proc (1 ,SIGTERM ,1 );
[reasons deleted]
Is using a signal the appropriate thing to do anyway?
Wouldn't there be better solutions?
Perhaps a mechanism a user space program can use to communicate to the kernel (ala arpd/kerneld message queues, or something like klogd). Then a more general user space tool could be used that would do policy appropriate stuff, ending with init 0.
mrc
Signature · 4 lines
Mike Castle Life is like a clock: You can work constantly [email protected] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen
Quoted 9 lines · Kurt Roeckx
Quoted 6 lines · Miquel van Smoorenburg
the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means "all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.-1 mean everything but init.
Oh, maybe you mean killall5 -TERM?
Which would send a SIGTERM to all processes but the one in his own session.
(Hey look, you wrote that manpage.)
Kurt
According to Kurt Roeckx:
Quoted 9 lines · Miquel van Smoorenburg
Quoted 4 lines
The "-1" means
"all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.-1 mean everything but init.
From the manpage:
Oh. OK, so this is yet another special case for init - forget to check those. Sorry about that (hey it's 01:53 here, I should be in bed). Yet I still think it'd be a better idea to use RT signals, see my other message in this thread.
Mike.
Quoted 12 lines
In article <[email protected]>,
Quoted 8 lines · Miquel van Smoorenburg
SIGTERM is a bad choise. Right now, init ignores SIGTERM. For good reason; on some (many?) systems, the shutdown scripts include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means "all processes except me". That means init will get hit with SIGTERM occasionally during shutdown, and that might cause weird things to happen.
Perhaps SIGUSR1 ?
Quoted 8 lines
In the immortal words of Max Headroom, t-t-talking to myself ;)
In fact, the kernel should probably use a real-time signal with
si_codeset to 1 for ctrl-alt-del, 2 for the powerbutton etc.It should first check if process 1 (init) installed a handler for that real-time signal. If not, it should use the old signals (SIGINT for ctrl-alt-del, SIGWINCH for kbrequest).
This is ugly as night, but SIGUSR1 looks okay.
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Hi!
Quoted 10 lines
Quoted 7 lines
Quoted 2 lines
Init should get to know that user pressed power button (so it can do shutdown and poweroff). Plus, it is nice to let user know that we can
Not so hasty ;)
drivers/acpi/events/evevent.c line 176
Quoted 2 lines
drivers/acpi/events/evevent.c +2
-0+printk ("acpi: Power button pressed!\n" ); +kill_proc (1 ,SIGTERM ,1 );[reasons deleted]
Quoted 8 lines
Is using a signal the appropriate thing to do anyway?
Wouldn't there be better solutions?
Perhaps a mechanism a user space program can use to communicate to the kernel (ala arpd/kerneld message queues, or something like klogd). Then a more general user space tool could be used that would do policy appropriate stuff, ending with init 0.
init _is_ the tool which is right for defining policy on such issues.
Take a look how UPS managment is handled.
Signature · 2 lines
Philips Velo 1: 1"x4"x8", 300gram, 60, 12MB, 40bogomips, linux, mutt, details at http://atrey.karlin.mff.cuni.cz/~pavel/velo/index.html.
Quoted 6 lines · Pavel Machek
Quoted 2 lines
Then a more general user space tool could be used that would do policy appropriate stuff, ending with init 0.
init _is_ the tool which is right for defining policy on such issues.
Take a look how UPS managment is handled.
A power failure is a different thing from a power button press. There are users (me for example) who want to have something different then "init 0" mapped to the power button, for example a sleep state (since my box doesn't have a dedicated sleep button). I doubt there are many people who want something else than a shutdown if the power is out (although I think there will be with suspend-to-disk working, so we might have to change UPS handling here).
My plan for power management was to have a special daemon that would decide what to do based on system state (battery status, local time, ...) and events (power/sleep button, last user logged out, ...) [I know that from a programmer's POV, both are events]. This daemon could, for example, make sure that no services are affected, for example by priming WOL and entering a not-so-deep sleep state instead of doing a suspend-to-disk if someone is still listening on a port after the "shutdown unimportant services" scripts have been run.
Simon
Signature · 3 lines
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Quoted 27 lines · Simon Richter
Quoted 7 lines · Pavel Machek
Quoted 3 lines
Then a more general user space tool could be used that would do policy appropriate stuff, ending with init 0.
init _is_ the tool which is right for defining policy on such issues.
Take a look how UPS managment is handled.
A power failure is a different thing from a power button press. There are users (me for example) who want to have something different then "init 0" mapped to the power button, for example a sleep state (since my box doesn't have a dedicated sleep button). I doubt there are many people who want something else than a shutdown if the power is out (although I think there will be with suspend-to-disk working, so we might have to change UPS handling here).
My plan for power management was to have a special daemon that would decide what to do based on system state (battery status, local time, ...) and events (power/sleep button, last user logged out, ...) [I know that from a programmer's POV, both are events]. This daemon could, for example, make sure that no services are affected, for example by priming WOL and entering a not-so-deep sleep state instead of doing a suspend-to-disk if someone is still listening on a port after the "shutdown unimportant services" scripts have been run.
Quoted 2 lines
Simon
(root@qwerty)-(02:32pm Mon Apr 16)-(root)
# cat /etc/inittab | grep -1 CTRL
# Trap CTRL-ALT-DELETE
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
I believe that what is being referred to is similar. In which case, you can put whatever the bleep you want here and do anything from popup a message saying, "Shutdown denied" to immediately poweroff.
-b
Signature · 5 lines
Three things are certain: Death, taxes, and lost data Guess which has occurred. - - - - - - - - - - - - - - - - - - - - Patched Micro$oft servers are secure today . . . but tomorrow is another story!
Hi,
Quoted 8 lines · Simon Richter
A power failure is a different thing from a power button press. There are users (me for example) who want to have something different then "init 0" mapped to the power button, for example a sleep state (since my box doesn't have a dedicated sleep button). I doubt there are many people who want something else than a shutdown if the power is out (although I think there will be with suspend-to-disk working, so we might have to change UPS handling here).
And why not do exactly this with init? Have a look in /etc/inittab:
% grep power /etc/inittab
# What to do when the power fails/returns.
pf::powerwait:/etc/init.d/powerfail start
pn::powerfailnow:/etc/init.d/powerfail now
po::powerokwait:/etc/init.d/powerfail stop
You can shut down your machine there, but you can also have it play a cancan on power failure. It is up to your gusto. And now tell me, why not choose a similar approach, but instead reinvent the wheel and create a completely new mechanism?
Andreas
Signature · 2 lines
Besides, I think Slackware sounds better than 'Microsoft,' don't you? -- Patrick Volkerding
Quoted 8 lines · Andreas Ferber
Quoted 1 line
A power failure is a different thing from a power button press.
And why not do exactly this with init? Have a look in
/etc/inittab:You can shut down your machine there, but you can also have it play a cancan on power failure. It is up to your gusto. And now tell me, why not choose a similar approach, but instead reinvent the wheel and create a completely new mechanism?
Because we'd be running out of signals soon, when all the other ACPI events get available.
Simon
Signature · 3 lines
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Hi!
Quoted 11 lines
Quoted 8 lines
Quoted 1 line
A power failure is a different thing from a power button press.
And why not do exactly this with init? Have a look in
/etc/inittab:You can shut down your machine there, but you can also have it play a cancan on power failure. It is up to your gusto. And now tell me, why not choose a similar approach, but instead reinvent the wheel and create a completely new mechanism?
Because we'd be running out of signals soon, when all the other ACPI events get available.
There are 32 signals, and signals can carry more information, if required. I really think doing it way UPS-es are done is right approach.
Pavel
Signature · 2 lines
I'm [email protected]. "In my country we have almost anarchy and I don't care." Panos Katsaloulis describing me w.r.t. patents at [email protected]
Quoted 6 lines · Pavel Machek
Quoted 2 lines
Because we'd be running out of signals soon, when all the other ACPI events get available.
There are 32 signals, and signals can carry more information, if required. I really think doing it way UPS-es are done is right approach.
Okay, but at least take a better signal than SIGINT, probably one that the init maintainers like so it gets adopted faster (or extend SIGPWR).
Simon
Signature · 3 lines
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Hi,
Quoted 3 lines · Simon Richter
Okay, but at least take a better signal than SIGINT, probably one that the init maintainers like so it gets adopted faster (or extend SIGPWR).
Extending SIGPWR will break inits not yet supporting the extensions, so this is IMO not an option. There should be used some other signal which is simply ignored by an old init.
If we are actually introducing this new signal, maybe we should in turn also provide for a generic init signalling API which could be used later by other subsystems also? The distribution of such events to other userspace processes (if there are some that want to receive a subset of the events) can be perfectly done by init, so we should IMO keep this stuff out of the kernel (I don't think that the processing of such events will ever be performance critical).
Andreas
Signature · 2 lines
Of course you can't flap your arms and fly to the moon. After a while you'd run out of air to push against.
Quoted 6 lines · Andreas Ferber
Quoted 2 lines
Okay, but at least take a better signal than SIGINT, probably one that the init maintainers like so it gets adopted faster (or extend SIGPWR).
Extending SIGPWR will break inits not yet supporting the extensions, so this is IMO not an option. There should be used some other signal which is simply ignored by an old init.
Make it a config option then; the short description says "read help", the long help says "you need init version x.y". People compiling their own kernels should know what they're doing, and distributors usually know what init they are packaging.
Quoted 5 lines
The distribution of such events to other userspace processes (if there are some that want to receive a subset of the events) can be perfectly done by init, so we should IMO keep this stuff out of the kernel (I don't think that the processing of such events will ever be performance critical).
Fine with me as long as I get a decent interface where the policy manager can plug into. :-)
Simon
Signature · 3 lines
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
Quoted 8 lines · Simon Richter
Quoted 4 lines
Extending SIGPWR will break inits not yet supporting the extensions, so this is IMO not an option. There should be used some other signal which is simply ignored by an old init.
Make it a config option then; the short description says "read help", the long help says "you need init version x.y". People compiling their own kernels should know what they're doing, and distributors usually know what init they are packaging.
The problem with this is that there is no single init. Most distribution run the same SysV init, but there are quite a few init replacements around. Should we really break all of them? We can simply use another signal and build a generic (and extensible) signalling mechanism around it, so I don't really see a reason why we should break old inits.
Andreas
Signature · 2 lines
Insults are effective only where emotion is present. -- Spock, "Who Mourns for Adonais?" stardate 3468.1
On Tue, 17 Apr 2001, Andreas Ferber wrote:
[Extending the current signalling mechanism]
Quoted 3 lines
The problem with this is that there is no single init. Most distribution run the same SysV init, but there are quite a few init replacements around. Should we really break all of them?
We don't break anything as long as noone sets the config option. People who want to use this feature need a current init.
Simon
Signature · 3 lines
GPG public key available from http://phobos.fs.tum.de/pgp/Simon.Richter.asc Fingerprint: DC26 EB8D 1F35 4F44 2934 7583 DBB6 F98D 9198 3292 Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!