alternatives for the Big Red Switch

consider journaling...

From Mark Morshedi

Answered By Thomas Adams, David Mandala, John Karns, Rick Moen, Mike "Iron" Orr, Didier Heyden, Heather Stern

What if the only option is to use the power switch to turn off the system. there are times that mouse doesn't work and keyboard is dead. how does one manages that without destorying the file system.

thanks

[Thomas] My first indication is that this is VERY much hardware specific. You should check that your motherboard can handle processes like the one that you wish to implement under linux.

Typically the programs that you would want to use are: "apm" which is most likely, the program that will control the "power-down" feature via the power button anyway, and also "lm_sensors" so that you can get the current state of your system.

As far as not allowing the filesystem to get mangled, you can set the maximum mount check point to an arbitrary value (I have it set at 100), using the "tune2fs" program. Thus you can specify:

tune2fs -c 100

means that your filesystem WONT be checked until it has been mounted 100 times. You can extend this further to say that:

tune2fs -i [d/m] whereby you can set the next check to
be in either days or months. Have a look at "man
tune2fs" for more details.

[Heather] Note that lm_sensors is specifically not recommended for some hardware; some thinkpad models crash hard and in fact the hardware suffers wickedly (see https://www.linux-thinkpad.org for details). Do check the internet for comments about lm_sensors and your motherboard before just brazenly invoking it.

[David] One can try the three finger salute Control Alt Delete which sometimes will cause a orderly shutdown and restart. Or one can use the ext3 filesystem option on newer versions of Linux which are safer to data loss.

If the machine is networked you could try sshing or telnetting into the locked machine, sometimes the console is locked but the machine is still active on the network and you can gain control that way.

[John] Re: journaling filesystems (ext3 mentioned below) I've been very happy with reiserfs over the past 18 months. Then there is the SGI (?) contributed XFS. See the LG issue 68 article about journaling filesystems for more info about them.

The magic SysRQ can also help, unless the kernel is locked up hard. It's worked for me on a number of occasions. For a system lock-up, the key sequence that I most often use is Alt-SysRq-S, Alt-SysRq-U, and Alt-SysRq-B which syncs buffers, unmounts fs's, and reboots, respectively. You may need to recompile your kernel to enable the feature though. For moe info, see /usr/src/linux/Documentation/sysrq.txt

[David] I remember reading somewhere how to hook up the power switch on an ATX power supply to do an orderly shutdown but I don't remember where. Anybody else remember?

[Rick] You might be thinking of Joris van Rantwijk's Linux PowerSwitch Driver. Description: "The powerswitch driver makes it possible to use the ATX power button on your computer to shutdown Linux. You simply press the power button, and the driver shuts down Linux and powers off the machine, just like the shutdown command does."

https://deadlock.et.tudelft.nl/~joris/powerswitch

A different approach:

https://www.geocrawler.com/archives/3/38/1999/9/50/2611153

Or a kernel patch for the ACPI code:

https://www.cs.helsinki.fi/linux/linux-kernel/2001-31/0968.html

[Iron] Since this is a different driver than the keyboard driver, it may work even when the keyboard doesn't respond. However, if not losing data is your primary concern, the first step to do is to switch to a journalled filesystem. It's easy to switch from ext2 to ext3.

1. Make sure your kernel has ext3 support compiled in. (Not a module, because you don't want it to fail if something happens to the module files.)
2. Boot to single-user mode (or use "telinit s").
3. For each filesystem:
   1. Verify it's unmounted or mounted read-only.
   2. Run "tune2fs -j /dev/THE_PARTITION".
4. Change "ext2" to "ext3" in /etc/fstab for the affected filesystems.
5. Switch back to multi-user mode.

You can also place /usr on a separate partition and mount it read-only except when installing software, to prevent those files from being corrupted in an unclean shutdown.

Make sure your rescue floppy (from your distribution, www.toms.net/rb/, etc) has support for the journalled filesystem you're using, or you won't be able to repair it from the floppy. Last I saw, Tom's supported ext3 out of the box, but for ReiserFS you had to put a custom kernel on the floppy. You may also want to leave /boot as ext2 (mounted read-only of course) to ensure it's repairable from the widest variety of rescue floppies, should the need ever arise.

Of course, you'll also want to determine why the keyboard is not responding and how to fix it. However, if you're stuck with unreliable hardware, immature drivers for your gee-whiz must-have peripherals, or you occasionally run out of both memory and swap, there's not much you can do except press the reset button or the power switch.

[Didier] I'm being rather off-topic here, but this summarizes perfectly the problem I had with my old graphics board -- a hardware issue ... seemingly solved by replacing the defective (or MVP3-incompatible) thing with another video card.

[Iron] But your first line of defense when the console hangs is to try to ssh or telnet in from another computer, because usually those services are unaffected. It may take a long time if the system is "thrashing" (meaning free memory is so low it's constantly swapping to disk), but you may be able to do a clean "halt" or "reboot" command that way.

[Didier] Regarding 'ext3' however, it may be worth mentioning the following discussion about a data corruption bug recently found in the 2.4.20 kernel:

https://kerneltrap.org/node.php?id=515

The funny thing is, ever since I started using 2.4.x kernels, and regardless of the actual 'ext' filesystem subtype, I've had to 'sync' multiple times and introduce artificial delays right before powering off the beast, otherwise the filesystems are almost invariably found to "have not been unmounted cleanly" on the next boot.

[Heather] The nature of the problem, and a workaround, is summarized nicely on this kernel-traffic entry: https://kt.zork.net/kernel-traffic/kt20021209_195.html#16

This bug has been caught and the patch is now available; to be safe you need to be either using an early enough kernel (the nasty bug was introduced in 2.4.20-pre5, but I think I saw discussion about interaction with a more subtle bug that lurked in the 2.4.19 series) or a late enough one (this one was nailed in 2.4.20-pre1, and two more notable ext3 bugs were nailed in -pre2).

When I realized that some of my dev work was going to heavily crash my development workstation, I decided I needed journals; saving everything aside for a thorough reiserfs makeover looked like no fun, so ext3 was my first try. That was when 2.4.19-pre10 was current and I've not encountered any sync problems; I'd certainly know, because a lot of my testing involves swapping drives around, so I'm up and down all the time deliberately as well. Also, It's not at all clear whether this ever affected the backported-to-2.2.x ext3 support, since the main flaw was in an optimization trick.

There was apparently some benchmark comparing reiserfs and ext3 mid-year 2002; it generated an awful lot of mailing list traffic at the time, easy to find in Google/linux when looking for both keywords together.

Meet the Gang   1   2   3   4