( Please forgive my typo in Subject: )
My original query:
> I'm getting this today on my SS10 running 4.1.4:
>
> Jan 23 12:44:22 titania vmunix: /: file system full
>
> but here is the relevant output from df:
>
> Filesystem kbytes used avail capacity Mounted on
> /dev/sd0a 30807 13482 14245 49% /
>
> Does this indicate the drive is dying or something else bad? I am able
> to copy file to / without getting the FS full message, which worries me.
The answer:
I still don't know. I haven't seen the message for 24 hours, so I think,
as many of the responses indicated, that there was an open file or
something along those lines which wasn't shown under df. Helpful
suggestions were: out of inodes (df -i), which I wasn't; /tmp filling up,
which is linked to /usr/tmp on a seperate filesystem; and mail spool or
/var full... both /var and /var/spool/mail are on seperate filesystems,
and neither was full.
I had 10 reponses in less than an hour, and continue to be impressed by
the friendly and knowledge people on this list. Several responses follow:
---- From: David Willard <dwillard@scires.com>Hi Tim, Could be that a process is writing to a file but has not closed the file yet. The space used by this file won't show up in a df. Or perhaps someone printed a rather large file??
Hope this helps, good luck! ---- From: Nicholas R LeRoy <nleroy@norland.com>
Do a 'df -i' and check the # of free inodes. Could cause the same kind of problem. Just a thought. ---- From: Tim Carlson <tim@santafe.edu>
Just a thought, but could your mail spool be on / and you are getting a mail bomb that fills up / and then gets deleted when it can't write anymore space? See if you have some big sendmail process that comes and goes, and check the incoming mail queue. ---- From: Daniel Lorenzini <lorenzd@gcm.com>
You probably have a job that sorts a big file. It fills up the disk (the default temporary directory that sort uses is /var/tmp) and the job fails. Since sort cleans up after itself and removes the temporary files, you have to try to track it down by asking people if their jobs are mysteriously failing or by some other means. ---- From: Nadya Williams <nadya@bog.ucsd.edu>
It is unlikely that your drive is dying, just the output of your df indicates that system came back to normal. Look at the file /var/adm/messages, it will have all the timed entries when / was full. Depending on your partitioning (/var or /tmp are the same as /) someone may have overloaded it with a big file. It happens for example if /var resides on the same partition as / and someone tries to send a huge mail file (some sendmail allows that), or someone sends a big file to a printer, (the directory is /var/spool/lpd). For /tmp it is similar. Depending on how / was overloaded your actions will be a bit different. ---- From: Stephen Harris <sweh@mpn.com>
Is /tmp on the / filesystem? Or /var/tmp ? If so, then possibly a temp file filled it up... (My cnews "mkhistory" command does this once a week :-( ugh...) ---- From: Jim Harmon <jim@telecnnct.com>
Do you have any other filesystems over 95%?
I think this might be -say- the syslog or /var/spool directory is running out of room and something you're running as root from the / directory may not be able to append to a log or system file somewhere else. ---- From: Matthew Stier <Matthew.Stier@MCI.Com>
Look for transient problems. Someone extracting a file, or starting an editor, and the /tmp, /var, or /var/tmp directories are with the '/' partition.
Is this from the console, or via syslog? (Syslog has a nasty habit of recording incidents against the host it received the report from. If C reports to B and B reports to A; C's reports will appear to have originated on B) ----
Thanks again,
Tim
==== Tim Buller buller@math.ukans.edu Math Department Systems Manager Snow Hall 643 University of Kansas, Lawrence, KS 66045 913-864-7311
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:43 CDT