Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Wed, Sep 05, 2001 at 10:18:15PM -0400, Duane Morin wrote: > Ok, this was weird. I sit at my gnome machine and login. I notice that some > of my applets don't show up on the panel. I've seen this before -- I call up a > terminal and try to run netscape. I get an X "Maximum number of clients > reached" error. By the way, if someone can tell me how to fix this without > rebooting, I'd love to hear it. But that's not today's problem... I've never seen that! How many clients do you have open? > I reboot. During shutdown, I get a message that says something like "/var > unmountable, drive is busy." That scared the bejesus out of me, because I > figure if I lose /var I'm at serious risk of booting into a non-bootable > machine. But everything booted fine, and there was no evidence of a problem > with /var. Probably this: umount: /var: device is busy Often this is because you're sitting in /var (or down it somewhere) when you shut down. It can't unmount the filesystem, because you're in it. It can also happen if you've got some other process which has a file in /var open. After shutting down services (like sendmail, syslog, etc), your system will send all processes the SIGTERM signal, which should cause them to clean up and terminate, and close their open files. That will usually allow the system to umount the filesystem on a second try, preventing any problems. If you ran shutdown in /var, it might result in the filesystem being un-umountable, requiring an fsck. This can also happen if a process which lives in /var or has a file open in there somehow gets wedged in I/O wait state ( 'D' status in the ps output). These processes are generally uninterruptable, and even kill -9 won't kill them. In these cases, the fs will not umount cleanly, and you'll have to fsck. Loosing /var isn't TOO much of a problem, as the only thing "important" that lives there is your mail spool. Most of what's left is things like log files and state files, which will be re-initialized after the FS is repaired anyway, if they're missing. -- --------------------------------------------------- Derek Martin | Unix/Linux geek ddm at pizzashack.org | GnuPG Key ID: 0x81CFE75D Retrieve my public key at http://pgp.mit.edu - Subcription/unsubscription/info requests: send e-mail with "subscribe", "unsubscribe", or "info" on the first line of the message body to discuss-request at blu.org (Subject line is ignored).
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |