On 5/15/2010 3:03 AM, Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Friday, 2010-05-14 at 20:55 -0700, Marc Chamberlin wrote:
...
FWIW I have seen another aspect of what I consider is a serious design flaw of the Linux kernel, in the shutdown/reboot processes. Some programs (MythTV comes immediately to my mind) can actually intercept the shutdown/reboot request and prevent it! And man does that infuriate me when I see it happen!!! When the OS receives a shutdown or reboot request, NOTHING short of a serious hardware failure should prevent it, IMHO. And NO app or process should EVER be allowed to prevent it. A shutdown or reboot request may have been initiated in response to an emergency, (especially in a situation like mine where I am remotely administering a computer and cannot be there to hit the power down button) therefore the Linux kernel must absolutely honor the request and force the shutdown or reboot to take place, regardless of any protests/failure from some darn app or process!
Are you sure it is the kernel that is at fault here, or is it the stop script (not the kernel) that is stoped/aborted?
I guess it is the script, and this is not at all part of the kernel. It is part of the distribution, the basesystem packages. Probably initd or rc.
Interesting question Carlos... Though I am not a guru on Linux, per say, I am a computer scientist and have written enough operating systems in my career to know where responsibilities should be delegated. Guess I probably should find some of that spare time I keep losing and study Linux deeper.. ;-) Almost every operating system I have worked with places the task manager/scheduler inside the protected space of the operating system kernel. This is a critical region of code and it is within the scheduler that a shutdown or reboot request should be acknowledged and ultimately handled, if need be. If the Linux designers want to spawn off a task to handle shutdown/reboot requests, or signal running tasks that they need to prepare for a system shutting down, that is fine, BUT the task manager/scheduler has the responsibility to force the shutdown should some task or process fail, including any such task spawned to process shutdown scripts. Any task or process can fail, for any number of reasons! Usually that is handled by setting an event timer of some kind, which can interrupt any task or process and resets the execution back to the kernel task manager/scheduler. This in turn can cause it to kill the offending process and proceed with the shutdown/reboot. If this is all done properly, then the code in the kernel space is pretty well protected from any form of memory corruption, which could cause the kernel to crash. And crashes do not normally lead to symptoms such as I and others here are reporting, i.e. intercepts of the shutdown/reboot request or simply closing X and resetting the runlevel to 3 with a basic terminal and asking the user to log in.... This has to have been done intentionally, and I am strongly arguing that this design is DEAD WRONG period. After a shutdown or reboot request has been made, the Linux OS/Kernel must see to it that it happens expeditiously, and enters into a state immediately that prevents anything else from happening until the shutdown process is complete, or the reboot process re-initializes the system for booting back up... That is a fundamental requirement of all computer operating systems, since the request to shutdown or reboot may have been initiated by an unforeseeable emergency of some kind. (Though I admit Windoz violates this principal as well, with their insistence on installing updates after a shutdown/reboot request has been made. And that also infuriates me to no end!) Marc..