Pages: [1] :: one page |
|
Author |
Thread Statistics | Show CCP posts - 0 post(s) |
Percussor
Caldari Hydra Alliance
|
Posted - 2007.11.08 19:10:00 -
[1]
While I don't have an answer to why your system is crashing(which after trolling a bit seems to be happening for quite a few) I do have a small trick that some haven't heard of to more gently recover their system. When Linux crashes and you have to cold reboot, there are all kinds of file consistency problems. The solution is the SysRq key. To help turn on the Magic SysRq key. First thing is to check if its compiled into your kernel by checking if the file /proc/sys/kernel/sysrq exists if it does your pretty much all set, if you don't you'll have to recompile your kernel with CONFIG_MAGIC_SYSRQ set (It's under Kernel hacking menu). To then enable the option either do 'echo 1 > /proc/sys/kernel/sysrq' every time you boot or add the line 'kernel.sysrq = 1' to your /etc/sysctl.conf file and it'll be set every boot. Now what is this for once its installed and turned on? You can issue command straight to the kernel. The string to remember is REISUB, that's how to reboot your computer safely. Just hold Alt-SysRq(Also the Print Screen Key)-R, then wait a second, Alt-SysRq-E... basically R - puts keyboard into raw mode, takes it back from the xserver which steals it E - sends terminate signal to all tasks, tells them to gracefully shut down I - sends kill to all tasks, forces it to quit S - sync all files, finishes writing everything to disk U - unmounts all filesystems and remounts readonly B - Reboot
This is very useful when screwing about with proprietary drivers and/or anything that can destroy your terminal access(namely the X server)
For more info: http://en.wikipedia.org/wiki/Magic_SysRq_key
|
Solbright altalt
|
Posted - 2007.11.08 21:13:00 -
[2]
All I can say is the filesystem handlers need a good kick up the ass for not putting the HDD in a good state in short order.
In fact my personal opinion is if the system can't just handle the main switch being turned off then the system needs fixed.
|
Percussor
Caldari Hydra Alliance
|
Posted - 2007.11.08 22:28:00 -
[3]
Well most modern filesystems use journaling and thus a quick yank of the power will guarantee the filesystem metadata is consistent, aka no inodes for nonexistant files, block bitmap matches on disk use, etc. But very few (ext3 with a specific non-default option) journal the data as well. So while your file might fill the correct amount of disk, the contents could essentially be garbage. On top of that any cache or buffers not flushed could lead to loss of data, and in the event of a crash this can sometimes include critical logging information to help diagnose that very crash.
|
Bentula
|
Posted - 2007.11.09 08:32:00 -
[4]
Edited by: Bentula on 09/11/2007 08:32:21
Originally by: Solbright altalt All I can say is the filesystem handlers need a good kick up the ass for not putting the HDD in a good state in short order.
In fact my personal opinion is if the system can't just handle the main switch being turned off then the system needs fixed.
Data journaling is too huge of a performance hog. Also nobody uses synced write on harddrives, its preferable for changes to not get written instantly but buffered instead and written in bulk.
Data security is working very much against speed here, there simply is no way to get both. Also, to answer you directly, the system can deal just fine with the powerswitch turned off, unless your in the middle of upgrading core system files. The question is wether you can deal with getting whatever data you where currently working with messed up.
Usually its only stuff in /tmp and swap that gets messed up so people dont tend to notice, also since only write changes are problematic there basicly isnt much that can happen to the programs themselves as they usually do not get written to in normal use.
|
Solbright altalt
|
Posted - 2007.11.11 20:41:00 -
[5]
I notice how you both ignored the most important part - "In short order".
Maybe I shouldn't have made the second comment. It wasn't something that needed a response in the general computing environment.
|
Snowcrash Winterheart2
|
Posted - 2007.11.11 21:26:00 -
[6]
Which the sysReq above is good stuff, another method you might want to try is this...
If you're desperate, try pressing the power button. Not press & hold, just tap it once. Usually X has gone mental but the underlying ACPI watcher is alive and well, thus the system comes to a nice halt writing out all the logs needed as it goes (hopefully).
Another alternative is, if you've another machine... ssh in to the busted box and kick X. On Ubuntu restarting GDM will cycle the whole X session (sudo /etc/init.d/gdm restart).
Very rarely is it a full on kernel panic that's stopped the GUI from responding.
|
roigon
|
Posted - 2007.11.14 00:12:00 -
[7]
magic sysrq is a life safer, although i can't actually prove that since i make it a good habit of using it :)
but before going as far as to try that, or go trough the hassle of ssh'ing to your box, you might first want to try CTRL+ALT+F1 or/and CTRL+ALT+BACKSPACE
because while there are lots of cases that X steals your keyboard while croaking, it also is quite frequently just the game that freezes but not (yet) X.
using the above combination will hopefully take you back to either a terminal or your graphical login screen. unsaved data might still be gone, but at least not corrupt. (although the crashed application might of course have written of some corrupted data)
Also to add to the multitude of reasons you want to use magic sysreq; Hard reboots while your disks might still be writing/reading could lead to unwanted physical damage to your disks. This doesn't mean that the disk will be broken or something, but it will take some life out of the disk. Although i have to admit, this was a issue with old disk AFAIK and i don't know if modern disks/computers are better at dealing with cutting power. But better safe then sorry.
|
Cardice Makar
Caldari Dark Knights of Deneb Against ALL Authorities
|
Posted - 2007.11.14 18:22:00 -
[8]
Originally by: Percussor
R - puts keyboard into raw mode, takes it back from the xserver which steals it E - sends terminate signal to all tasks, tells them to gracefully shut down I - sends kill to all tasks, forces it to quit S - sync all files, finishes writing everything to disk U - unmounts all filesystems and remounts readonly B - Reboot
lol, made me chuckle, there's a good mnemonic for this: RSEIUB = Raising Skinny Elephants Is Uttery Borring; it doesn't make a whole lot of sense, but it makes me smile every time I use it [better than crying... which is the alternative].
I should hope that Ubuntu would have the Magic SYSRQ flag set in their default kernel.
|
|
|
|
Pages: [1] :: one page |
First page | Previous page | Next page | Last page |