Subject: Re: ctrl+alt+del
To: NetBSD User's Discussion List <netbsd-users@netbsd.org>
From: Greg A. Woods <woods@weird.com>
List: netbsd-users
Date: 06/11/2001 18:00:35
[ On Monday, June 11, 2001 at 22:40:42 (+0200), Matthias Buelow wrote: ]
> Subject: Re: ctrl+alt+del
>
> The whole idea of the ctrl+alt+del issue is that it is an _emergency_
> mechanism, usually used when the machine is fucked up due to a bad
> kernel or hardware, or completely overloaded.

So then jump into DDB (currently <ctrl>+<alt>+<esc> on alpha, hpcmips,
and i386) and then type "sync<CR>" and hope it works.

That's what it's there for!

>  There is little gain
> in having userland tools watch for an abnormal termination request
> by the user when they don't even get scheduled, the system is out
> of swap, or they crash immediately, or whatever.

That's exactly what I've been trying to say.....

>  That's why in
> systems like Lignux, FreeBSD etc. the console driver checks for
> the vulcan nerve pinch[1] and runs a kernel space initiated system
> reboot.  This key combination method should be the last resort
> (apart from the kernel debugger, of course) to bring the system
> back into operation, without losing disk buffers in the netherworld.

see below...

> Popping up the debugger on ctrl+alt+del is often inacceptable,
> imho, since in an unsecured environment (such as a public computer
> pool), you do not want users mess with kernel data structures.

OK, fine, I agree in those scenarios, so don't offer DDB on those
machines....

Are you sure you want a console reboot to work there too though????  I
sure wouldn't, and in fact on such machines I would have a soft-power
switch or similar installed in place of the real reset switch if
"customer recovery" was desired, and I might even have the power switch
secured too, depending on how "public" the machines were.

> However, allowing them to safely reboot a workstation (i.e., without
> just hitting the switch, which would happen otherwise, no matter
> if you forbid it or not, I have done that myself often enough) in
> case the system is completely unresponsive or similar, makes sense.

NetBSD doesn't get in that state very often, at least not in releases
which are what should be running on public computer pools!  Not only
that, but if it does then the reset switch might be necessary anyway.

(BTW, I've only accidentally powered down running systems after having
become accustomed to using the soft-power switch on my AT&T 3B2s. :-)

> At least you get a clean reboot then, without having fsck to wipe
> up the remains.

That's a fallacy.  Most often NetBSD gets frozen because of hardware
failures (which seem particularly prevalent on PC hardware).  Even DDB's
"sync<CR>" won't help avoid an "fsck" in any of those cases, or even The
Big Red Switch in many cases.

As the other recent big thread on this list says:  NetBSD is not Linux!  :-)

The only reasonable suggestion so far, other than the implied "do what
DDB 'sync' does" of course, is to send SIGPWR to "init" and have it
invoke "halt", and that's not going to be any different than any of the
zillions of other simpler ways to invoke halt/reboot/shutdown on demand.

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>     <woods@robohack.ca>
Planix, Inc. <woods@planix.com>;   Secrets of the Weird <woods@weird.com>