Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

/var is busy? the hell??



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
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org