> On Sat, Jun 27, 1998 at 07:41:38PM +0200, Ragnar Hojland Espinosa wrote:
> Hi,
> > On Sat, 27 Jun 1998, Myrdraal wrote:
> > > to leave it on all the time. Also, I can see a scenario where a server is
> > > crashing often - So you enable sysrq, and catch the next crash. Personally,
> Well, personally I only see any of this making a difference if the system
> console is publically accessable (ie, library computers or something.) - This
> is definately not the most common use, IMHO.
Well... I think I should mention that there are cases where leaving the
computer vlock'd is relatively safe - as in people aren't stupid enough to
break the hardware but are stupid enough to "press random keys"... I think
a password-protected sysrq would be useful in some situations... especially
when somebody bothers to implement some more multi-user friendly console
things like a vlock equivalent which won't be able to lock "unused" ttys;
just current user's ttys... [and yes such things would be really useful
for real multi-user computers where users don't trust each other;)]
> > So, you leave sysrq on so lusers can play with it until it crashes and you
> > go have a look?
> If it crashes without sysrq, depending on how badly it crashed you might have
> been able to sync/umount/reboot and not have to fsck or lose any data.
> > Or, supposing you sit in front of the computer waiting for
> > the crash, why dont you just boot a kernel with SysRq?
> Well, this requires a recompile/reboot. ('Okay,' you might say, 'But you had
> to reboot anyhow if it crashed.', that's true. But you still do not have to
> recompile. Besides, if the X server crashes, you don't have to reboot the
> system if you can just slam alt-sysrq-r, then run something to reset the
> video mode.)
And sometimes the bugs don't show up easily... as in if you recompile the
memory layout will propably be a bit different and so on...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu