Dear Sun-Managers
Thanks very much to all who responded:The general direction of answers
pointed to a lack of sufficient swapping space in the /tmp directory.
The suggestion of creating a /altusr/tmp linked to /tmp is the way
I'll go.
Thanks too to any who may have responded after this was posted.
Michael Blandford <mikey@lanl.gov>
/tmp is in /. Thats all you have to fill up to get those messages.
raju@intelihealth.com
check cron jobs that write to / (probably /tmp or /var/tmp) the create temp.
files and then delete them. Your root partition might be filling up and
then the job is deleting files so it goes back to 58% ...
Brent Chivers <bchivers@karoshi.mitretek.org>
We were stumped for a while by a full root filesystem. We eventually
discovered some files hidden under a mount point -- at some point in
the past the system had been run without a disk partition mounted and
it created some log files deep down in the directory tree, and then
later things were mounted correctly -- the disk space was consumed
but hidden.
But in our case, df was reporting that the partition was full.
When we hunted around we couldn't find anything out of place or
that we should delete. Maybe whatever is filling up your root
is trying to create a large file, and then dying when it fails,
freeing up the space again right away. Anything going on in /tmp?
Anyway, see whether you get the same info from df and du -d.
John Ballard <johnb@ocean.washington.edu>
It looks as if some process is using the tmp
file in / as temporary storage. This is exactly
what we get when someone trys to print a very large
file. So whwn you notice it, the print job has completed
and there is plenty of room left in / .
You will need to monitor the system to track it down.
"Matthew Stier" <mstier@hotmail.com>
With such a small root partition, it really would take much to fill it up.
An application that creates a temp file, finding that the filesystem is full
throws it away and exits.
You mention that /var (and there by /var/tmp) is in the root partition, but you
don't mention /tmp. (I'm not sure if tmpfs existed in 4.1.1 or not.)
negativl@netcom.com (Raymond Wong)
it's possible to run out of inodes, use df -i to check that.
It's also possible someone deleted a file from a process that hasn't
closed it yet... the blocks will still not be free. try rebooting
to see if that goes away.
reynolds@acetsw.amat.com (John Reynolds)
I would guess it's something transient going through the /var/spool
directories. Look for some large print jobs, or someone Emailing gif
files. Another possibiliity is a compiler that is trying to put large
files in the /var/tmp or /tmp directories. Check the modification
dates of the various directories in /var and see if any of them are
getting changed frequently.
Buddy Mecca <bmecca@wea.com>
Try looking in /var/log. If that's OK look in /var/spool/mail.
If that's OK, if you are using PC-NFS try looking in /var/spool/pcnfs.
Hope this helps!
boss@netcom.com (Todd Boss)
you don't ahve a specific partition set up for swap, so my guess is
swap is mounting itself on /tmp, which is part of / but won't show
up in a df -k b/c swap isn't generating any file system space...
bismark@alta.Jpl.Nasa.Gov (Bismark Espinoza)
You may have a process that has an open file to
/tmp.
jim@nga.com (Jim Roy)
On our similar setup, I get this sometimes when a large mail message
comes in, croaks for lack of space & then goes away, leaving little
in the way of tracks.
Somebody is probably opening a large temporary file of some sort.
Editors, the printer system, scrolling windows are some likely culprits.
Look in /var/spool and /tmp
cmconwa@sandia.gov (Christopher M. Conway)
You don't seem to have /tmp mounted from anywhere. That means you're using
/ for /tmp; with only 3MB free, you could fill that pretty quickly with,
say, a compile, and then have it go away by the time you looked. I'd bet
on that being the problem. Mount /tmp in swap or on a different file system
and that should take care of the problem.
trfrytz@sandia.gov (Teri Frytz)
Maybe your /tmp directory should be on it's own partition?
Marina.Daniels@ccd.tas.gov.au (Marina Daniels)
I suspect either someone is editing a large file using "vi" for example, which
would create a large file in /var/tmp temporarily (filling up root)
or else someone is sending a large mail message through - which would go into
/var/spool/mqueue while it was waiting to be delivered, or go into /var/mail
waiting for someone to get it with their pop account
robin.landis@imail.exim.gov
You haven't created swap space on the / partition have you? Would df -k
show what was mounted for swap in that partition? or /etc/vfstab would
tell. Hope this isn't a stupid suggestion.
steveb@pcs.co.uk (Steve Butterfield)
It could be that you are out of inodes rather than disk blocks.
df has an option to print the inode summary's - See man page for details.
Chan_Kar_Cheung.XSSC@fxap.xerox.com
Your root directory has only 2.9MB disk space. Some applications
like compiler use /tmp to store temporary files. If you were running
such applications, they may fill up the root directory.
One solution is to create a tmp directory in a partition like /altusr and
link /tmp to /altusr/tmp. All temporary files written to /tmp wil then
go to /altusr/tmp.
Kevin.Sheehan@uniq.com.au (Kevin Sheehan {Consulting Poster Child})
Probably somebody hosing /tmp, since it is not a separate or tmpfs based
file system. You might want to turn on accounting to see what commands
are running at the time. You might also want to assign quotas to see
if a given user is doing it.
"Mark.Phillips@UniSA.Edu.Au" <itumrp@lux.levels.unisa.edu.au>
Try running fsck on your root file system.
The original query follows ...
We have a small Sun IPC running SunOs 4.1.1. Lately the
log messages have begun to appear regarding full root system
Feb 28 18:20:46 elizipc vmunix: /: file system full
Feb 28 18:21:00 elizipc last message repeated 66 times
Feb 28 18:21:01 elizipc vmunix: /: file system full
Feb 28 18:21:04 elizipc last message repeated 14 times
Feb 28 18:21:37 elizipc vmunix: /: file system full
Feb 28 18:22:06 elizipc last message repeated 133 times
Feb 28 18:22:06 elizipc vmunix: /: file system full
Feb 28 18:22:15 elizipc last message repeated 37 times
However, root directory is at 58% capacity only.
Filesystem kbytes used avail capacity Mounted on
/dev/sd0a 7735 4048 2913 58% /
/dev/sd0g 143965 103979 25589 80% /usr
/dev/sd0h 7255 1 6528 0% /info
/dev/sd1a 722742 487726 162741 75% /home
/dev/sd1g 210095 143962 45123 76% /news
/dev/sd2a 722742 466682 183785 72% /home2
/dev/sd2g 210095 14023 175062 7% /altusr
I checked that /var/adm only had two log files messages and messages.0
and that similarly /var/log contains syslog and syslog.0
regards,
Michael
-----------------------------------------------------------------------------
Michael Tong Lee
Systems Manager
Elizabeth College _--_|\
256 Elizabeth Street / \
HOBART, Tas 7001 \_.--._/
v*
ph 03 6235 6520 TASnet: Eliz_Mike
fax 03 6231 2242 Internet: Mike.Tong.Lee@eliz.tased.edu.au
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:11:48 CDT