NOTICE: alloc: /: file system full
John Oliver
There are message files in /var/adm. Also, there is a cron log
someplace in /var. The message and cron log files can be truncated.
As far as I know, all of /var/sadm can be moved.
/var/sadm/patch may be large if you have installed a lot of patches. It
holds the backout patch directories so you can remove patches. It is safe to
remove any that you don`t expect to back out. Ususally, a patch either works
all the time or fails within a few days. If it doesn't fail, it is probably
safe to remove the patch directory from /var/sadm/patch.
John
********************************************************
* _--_|\ | j...@cc.uow.edu.au *
* / \ | That's the University of Wollongong *
* \_.--\_* <-- Wollongong is a city of 200,000 about *
* v | 100 km south of Sydney, Australia *
********************************************************
Carlos Munoz Tech Support
We are currently running a SPARC Classic under Solaris 2.3 with
a 450 MB Hard Disk.
A few days before a message has been appearing when working on
the system console.
It says: NOTICE: alloc: /: file system full
We have once the directory /var/mail & /var/tmp in the root partition,
but I already move it to the /export partition.
After that I get 1 Mega of free disk space under / but it is again
full. What files grow so the / partition eats this space?
We dont' use root often, we have another account with root uid (0)
with a homepath at /export/home/consola so its files dont occupy
the / root partition?
Could someone help.
Which files in the / partition could be move to another place so
that everything contiune working...?
Carlos R. Munoz
E-Mail: cmu...@ns.pa
Christian Iseli
|> A few days before a message has been appearing when working on
|> the system console.
|>
|> It says: NOTICE: alloc: /: file system full
|>
Take a look at /var/spool/lp/temp. It's a soft link to a directory
that contains the print spool for the local host. It seems that
the print daemon forgets to delete some old jobs at times. Don't know
why, but it happens here and it can get quite large.
--
Christian Iseli
LSL-DI-EPFL
Lausanne, Switzerland
Himanshu Gohel
>This is for Solaris 2.3
>
>
DON'T EVEN THINK ABOUT DOING THAT! /var/sadm is an IMPORTANT directory!
I removed some of the directories /var/sadm/pkg since there were many
directories like this:
SUNWcsu
SUNWcsu.2
SUNWcsu.3
...
SUNWcsu.11
And each one was taking up 20-50K (depending on which pkg it was). So
I foolishly decided to delete everything but the last patch directory,
in this case SUNWcsu.11.
But now the system is confused. It thinks that SUNWcsu is NOT INSTALLED!
So I can't install new patches that patch SUNWcsu. The solution to this
is to restore the /var/sadm/pkg/SUNWcsu, but it is NOT advisable to delete
any of the /var/sadm directories.
Maybe the poster meant /var/adm and not /var/sadm?
(WARNING! my reply address may be incomplete! Please use the one below)
Himanshu Gohel, Go...@csee.usf.edu
Computer Graphics and Geometric Modeling Research Group
U of South Florida, Tampa, FL 33620
Tim Evans
>This is for Solaris 2.3
>There are message files in /var/adm. Also, there is a cron log
>someplace in /var. The message and cron log files can be truncated.
>As far as I know, all of /var/sadm can be moved.
Whoa, there! /var/sadm contains the database of "packages" which
have been installed on the system. If you remove it, you will not
be able to install patches, de-install patches (or anything else),
etc. See the man pages for 'pkginfo' 'pkgadd' 'pkgrm' and such.
Also, if this is removed, you will not be able to upgrade to a
new OS release, since the system will have no records of what
has been installed.
--
Tim Evans | E.I. du Pont de Nemours & Co.
tke...@eplrx7.es.dupont.com | Experimental Station
(302) 695-9353/8638 (FAX) | P.O. Box 80357
EVANSTK AT A1 AT ESVAX | Wilmington, Delaware 19880-0357
Charles Lindsey
--
Charles H. Lindsey -------------------------------------------------------------
At Home, doing my own thing. Internet: c...@clw.cs.man.ac.uk
Voice: +44 161 437 4506 Janet: c...@uk.ac.man.cs.clw
Snail: 5 Clerewood Ave., CHEADLE, SK8 3JU, U.K. UUCP: mucs!clerew!chl
Marcos Della
: j...@UOW.EDU.AU (John Oliver) writes:
: >This is for Solaris 2.3
: >As far as I know, all of /var/sadm can be moved.
: Whoa, there! /var/sadm contains the database of "packages" which
: have been installed on the system. If you remove it, you will not
: be able to install patches, de-install patches (or anything else),
: etc. See the man pages for 'pkginfo' 'pkgadd' 'pkgrm' and such.
One thing that you can probably do is to remove the /var/sadm/patch
directory. There is a trade off by doing this however. If you
remove all the stuff in the patch directory, you will be unable to
back out any of your patches. Typically this is not a problem since
most people have more problems without the patches than with them.
What I do typically is to create some space on the /export area and
link the var/sadm/patch directory over there...
Other areas that can be cleaned (assuming of course that you did not
make a seperate partition for /var...) might be the /var/adm/message.[0-3]
files (these are backups rotated out once a week from the messages file)
or even the /var/lp/logs/lpsched.[0-2] and /var/lp/logs/requests.[0-2]
Best bet is to have the /var broken out into its own partition next time
you set up a machine and give root a few mb over the recommended amount.
--
,,,
(o o)
--------------------------oOO--(_)--OOo--------------------------
We are the Labs... Compatibility is irrelevant...
Prepare to be emulated...
Marcos R. Della Email: Marcos...@SunLabs.Eng.Sun.COM
Sr. Network Engineer Sun Microsystems Labs
Phone: 415/336-5551 Fax: 415/969-7269
PGP Fingerprint: AD 6C 63 DA 5D 69 8A 31 44 AF 2F B0 6F 14 36 18
Peter Ruprecht
|>
|> We are currently running a SPARC Classic under Solaris 2.3 with
|> a 450 MB Hard Disk.
|>
|> A few days before a message has been appearing when working on
|> the system console.
|>
|> It says: NOTICE: alloc: /: file system full
|>
|> We have once the directory /var/mail & /var/tmp in the root partition,
|> but I already move it to the /export partition.
|>
|>
|> Which files in the / partition could be move to another place so
|> that everything contiune working...?
|>
|> Carlos R. Munoz
|> E-Mail: cmu...@ns.pa
Carlos,
You might want to clean out various log files in /var periodically, such as
/var/adm/messages and the /var/spool/lp/logs for example. These can grow very
large and cause problems. Best of all, next time you set up a filesystem, put
/var on its own partition.
I have a somewhat related question, however. We occasionally get the
alloc: /: file system full
error message, but at times when we should have about 3MB available in /.
This space does NOT seem to be taken up in any files; I have searched particularly
carefully through all of /var. If I reboot, the missing 3MB reappears. Does
anyone have any ideas where it might have gone to? Is it a leak of some sort?
Thanks,
Peter
Ruth Milner
>: j...@UOW.EDU.AU (John Oliver) writes:
>
>: >As far as I know, all of /var/sadm can be moved.
>
>: Whoa, there! /var/sadm contains the database of "packages" which
>: have been installed on the system. If you remove it, you will not
>: be able to install patches, de-install patches (or anything else),
>: etc.
>
>directory.
Notice the original poster said *moved*, not *removed*.
It is a good idea to have /var in its own separate partition from /.
But in the meantime, you can probably *move* anything not needed at boot
time to another filesystem that it mounts, and symlink it in the original
place. No guarantees, but I can't see any reason why this wouldn't work.
/var/sadm is probably a good candidate for this.
--
Ruth Milner NRAO/VLA Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
Ruth Milner
>
>It is a good idea to have /var in its own separate partition from /.
>
>But in the meantime, you can probably *move* anything not needed at boot
Just as a clarification: you can't make /var itself a symlink; we tried it
and it doesn't work. :-) There are some things in /var that it looks for
at boot time (can't remember what now). There are also boot-time procedures
that look specifically for a partition mounted on /var and mount it if it
exists; but they can't follow symlinks. You'd have to do some major kluging
to get that functional.
Himanshu Gohel
>
>I have a somewhat related question, however. We occasionally get the
> alloc: /: file system full
>error message, but at times when we should have about 3MB available in /.
>This space does NOT seem to be taken up in any files; I have searched particularly
>carefully through all of /var. If I reboot, the missing 3MB reappears. Does
>anyone have any ideas where it might have gone to? Is it a leak of some sort?
Funny thing. Just the other day we noticed a similar problem. I was modifying
'xv' to recognize another file format. The resulting binary seemed to work
great, but soon after we started using it to quickly view 100s of images, we
got an error message from xv, and then from the system about insufficient space.
The system proceeds to lock up and a reboot is necessary. This problem has been
reproduced on two machines.
Like you said, /tmp (or /var/tmp) had a little space, but there are no large
files. It turns out there are supposedly unreferenced files which get cleared
via fsck and the space is retrieved on rebooting.
What I would like to find out is how to determine who is creating these
unref files, and if this modified version of xv is creating them, when and
where. Anyone have hints on how to do this?
---
Himanshu Gohel, Go...@rad.usf.edu
Patrick Britschgi, ETL H12, 24267,
>I have a somewhat related question, however. We occasionally get the
> alloc: /: file system full
>error message, but at times when we should have about 3MB available in /.
>This space does NOT seem to be taken up in any files; I have searched particularly
>carefully through all of /var. If I reboot, the missing 3MB reappears. Does
>anyone have any ideas where it might have gone to? Is it a leak of some sort?
Hello Peter, hi all
We've had a similar case some time ago: We had 4 MB used but not
referenced space in the /var partition. When fsck'ing the filesystem we
found unreferenced files, and fsck ended with $status = 8. We couldn't
find out the reason for those files for sure but we assume that it must
have been lost print bitmaps. The cure was easy: Do a proper fsck (in
single user mode and reboot afterwards).
before:
df
Filesystem kbytes used avail capacity Mounted on
/dev/sd2a 15335 11721 2081 85% /var
du
7654 /var
after:
df
Filesystem kbytes used avail capacity Mounted on
/dev/sd2a 15335 7409 6393 54% /var
du
7409 /var
fsck output:
Used space Assumption
4*1028096 Bytes lost print bitmaps
1360 Bytes ?
680 Bytes ?
By the way:
A4 (8.5" x 11") = 1.027 MB (300 DPI)
= 1.826 MB (400 DPI)
Does this help?
Patrick.
____________________________________________________________________________
Patrick M. Britschgi Voice: ++41 1 632 4267
Swiss Federal Institute Fax: ++41 1 632 1212
of Technology E-Mail: brit...@lem.ee.ethz.ch
Power Elecronics and
Electrometrology Lab (LEM)
ETH-Zentrum, ETL H12
CH-8092 Zuerich
Switzerland
Gary Andresen
Move the sadm directory to a disk with some room on it, then make a
soft link from the new location to /var/sadm. We have done this on a
handful of machines and it works great.
Gary Andresen
Senior Systems Engineer
BlueCross BlueShield of Oregon
100 SW. Market Street
PO Box 1271
Portland, Oregon 97207-1271
(503)220-3918
EMAIL: Gary.A...@bcbso.com
Ian Goldberg
Ruth Milner <rmi...@newshost.aoc.nrao.edu> wrote:
>Just as a clarification: you can't make /var itself a symlink; we tried it
>and it doesn't work. :-) There are some things in /var that it looks for
>at boot time (can't remember what now). There are also boot-time procedures
>that look specifically for a partition mounted on /var and mount it if it
>exists; but they can't follow symlinks. You'd have to do some major kluging
>to get that functional.
Huh?
calum[113]% ls -l /var
lrwxrwxrwx 1 root staff 8 Mar 18 16:08 /var -> /usr/var
We keep /var under /usr, with all the world-writable spool dirs on a different
partition.
- Ian
Ian Goldberg
Peter Ruprecht <rupr...@mildred.physics.ox.ac.uk> wrote:
>I have a somewhat related question, however. We occasionally get the
> alloc: /: file system full
>error message, but at times when we should have about 3MB available in /.
>This space does NOT seem to be taken up in any files; I have searched particularly
>carefully through all of /var. If I reboot, the missing 3MB reappears. Does
>anyone have any ideas where it might have gone to? Is it a leak of some sort?
>
>Thanks,
>Peter
This kind of thing happened to us once. The problem was an ftpd was holding
a (large) file open, but its directory entry had since been deleted. Since
Unix will only deallocate the space when no process references it, df reported
a higher disk usage than du. When the ftpd terminated (it was over a _really_
slow link), the disk space returned.
---------.. ._ _.------------
Ian Goldberg University of Waterloo PM+CS
iagol...@csclub.uwaterloo.ca
Geek Code 2.1: GCS/M d-- H+ s g+ p? !au a- w+ v- C++(++++) UUAOS++LS++++ P++++
L+(+++) 3- E---(-) N++ K++ W--- M-- !V -po+ Y+(++) t++ !5 j R
G'''' tv b+ !D B-- e+ u@ h(*) f+ r++ n+(-) y+
Andre Beck
Just for fun, init 1, umount /usr, and look where the link points now.
I bet there is a /usr/var subdirectory there with some stuff, which
is abandoned as soon as /usr is mounted on top of the /usr directory
of the root disk.
--
+-o-+--------------------------------------------------------+-o-+
| o | \\\- Brain Inside -/// | o |
| o | ^^^^^^^^^^^^^^ | o |
| o | Andre' Beck (ABPSoft) Andre...@IRS.Inf.TU-Dresden.de | o |
+-o-+--------------------------------------------------------+-o-+
Ruth Milner
Ian Goldberg <iago...@calum.csclub.uwaterloo.ca> wrote:
>Ruth Milner <rmi...@newshost.aoc.nrao.edu> wrote:
>>Just as a clarification: you can't make /var itself a symlink; we tried it
>>and it doesn't work. :-) There are some things in /var that it looks for
>>at boot time (can't remember what now).
>Huh?
>
>calum[113]% ls -l /var
>lrwxrwxrwx 1 root staff 8 Mar 18 16:08 /var -> /usr/var
>
>We keep /var under /usr, with all the world-writable spool dirs on a different
>partition.
Yeah, some clarification that was ... :-(
There are things the boot procedures want in /var during the early stages
of boot. /usr is mounted at this time, so your setup works. But if the link
points somewhere that isn't yet mounted, you'll run into (serious) trouble.
SunOS 4 didn't care about /var during boot; SunOS 5 does.
What I was trying to say :-) is that you have to be careful making /var a
symlink, which is what it usually winds up being if you move it into some
other partition with something else. If that partition is anything other than
/ (which it's presumably being moved out of) or /usr, you'll get screwed.