|[Home] [Credit Search] [Category Browser] [Staff Roll Call]||The LINUX.COM Article Archive|
|Originally Published: Monday, 9 October 2000||Author: Mike Baker|
|Published to: interact_articles_irc_recap/IRC Recap||Page: 1/1 - [Std View]|
Best of IRC for Monday, October 9th!
It's time once again for another edition of Best of IRC. As always, we'll be taking an in-depth look at some of the questions asked on #Linuxhelp. If you haven't already been to #Linuxhelp, you'll find instructions on how to get there at the bottom of the Live! page. Feel free to stop by and ask questions or possibly even answer a few!
<daemon> I have a question, my /dev is HUGE, how can I clean it up so the only things in /dev are devices actually in use?
<zdt> daemon don't touch /dev
<zdt> daemon because, it's utterly insane
<daemon> but it's HUGE;)
<daemon> it's ugly;)
<zdt> daemon so dont' look at it
<[MbM]> daemon: everything in there represents some form of hardware
<[MbM]> daemon: and deleteing it could have nasty side effects
<daemon> [MbM] sounds fun:)
The files you see in /dev are representations of hardware in the form of block and character devices. A block device is a piece of hardware that can be read in arbitrary orde,r such as a hard drive. A character device, on the other hand, has to be read in a specific order such as a serial port. Although you won't hurt anything in the permanent sense, you will be unable to get at the hardware the device represents; the loss of a device could easily render your system unusable.
The 2.4.0 kernels use a new system called devfs which replaces the current scheme in 2.2.x. On bootup, the devfs filesystem is mounted as /dev. devfs is a virtual heirarchial filesystem which in simple terms means that you only see the hardware you have in your system and it's organized according to how it's connected. An example of such would be that /dev/hda becomes /dev/ide/host0/bus0/target0/lun0/disc.
If it all sounds too confusing, don't worry. Until all programs get converted over to the new format, /dev/ide/host0/bus0/target0/lun0/disc will be linked to /dev/hda. It's not likely that 2.4.0 will be out soon either.
<aries> Keyboard locked out , mouse wouldn't move
<aries> any way I can kill netscape when that happens?
<sgi> It may have grabbed the X server and hung, that didn't freeze Linux.
<sgi> You can still kill it off.
<sgi> Connect from a remote machine and kill it.
<aries> ummm, dont have another machine
<sgi> You can also try CTRL-ALT-BACKSPACE.
<[MbM]> aries: try SYSRQ-S, SYSRQ-U, SYSRQ-B when you need an emergency reboot, killing the power will probably break your files
<[MbM]> sysrq incase not all keyboards mark it anymore is what ahppens when you hold alt-printscreen
<coder> whats the rq stand for
<[MbM]> coder: system request
<[MbM]> sysreq needs to be enabled for it to work, donno if it's on by default
<aries> SYSRQ-S to kill x, then I type (guessing) startx to restart x?
<[MbM]> aries: nope, s is for sync disks, u is for unmount disks, b is for reboot
<[MbM]> aries: /usr/src/linux/Documentation/sysrq.txt
<aries> ummm, what does sync disk do? (syncs the disks, but what do I need to do that fer)?
When you find yourself facing what appears to be a hung system, the last thing you want to do flip the power switch and force a restart. The reason for this is because the system constantly has files cached in memory; storing the files in memory is much faster than reading and writing them off the disk drive constantly. When you pull the plug on the system, all the files that had been cached in memory are lost. All that remains of those files are parts of the file before it was cached along with anything the kernel had time to write to disk; the act of writing a file to disk is often referred to as a sync because it syncronizes the data. It's then the job of fsck to find these files which are now in a corrupted state and fix them or remove the corrupted data. It's slow, and not very pretty sight.
So what can you do when the system hangs? It's rarely that everything locks. Often times it's simply the application that has locked up. In many cases you can simply switch to another virtual console and kill the offending application. Usually something like this:
In the case above, it was the X server that locked up, making it much harder to kill. You can't even switch consoles when X is locked. The first thing suggested was CTRL-ALT-BACKSPACE. This hotkey sequence will attempt to shutdown the X server with quite abit of force. If that doesn't kill it, there's still a fairly good chance the system is still alive. The next thing we should be doing is syncing our files. If we do have to cut the power, at least we won't have to deal with filesystem corruption; syncing is done via SYSRQ-S.
The sysrq key as mentioned above is the alt-printscreen combination on PCs. The sysrq keys can be very destructive if used incorrectly, or used on a server where the keyboard isn't secured. These keys are disabled by default. To enable these keys, you will need to recompile the kernel. After syncing the disks, the next thing to try is the Secure Access Key (SAK), SYSRQ-K. The SAK will kill all the programs on the current console, useful for not only locked programs, but also verifying that the login prompts are real and not just some program that looks like one.
If worse comes to worst and the system still can't be unlocked, then it's time to reboot. Try CTRL-ALT-DEL and see if you can bring the system down nicely. If that doesn't work, then try it again with SYSRQ-S SYSRQ-U SYSRQ-B or sync, unmount, reboot respectively. Finally, if nothing else, kill the power and hold on for a long fsck session.