Help! What's /var/sadm? /var filesystem full.
Ryo Furue
Our /var often overflows (filesystem full). I noticed that
/var/sadm uses 62MB out of our small 192MB /var filesystem.
What are the files in /var/sadm for? I want to delete them
or move them to other filesystems (using symbolic links),
but I don't know if it's harmless to do so. Could someone
please give me advice? We use Solaris 2.6.
Thank you for your attention,
Ryo
Alan Coopersmith
|Our /var often overflows (filesystem full). I noticed that
|/var/sadm uses 62MB out of our small 192MB /var filesystem.
|What are the files in /var/sadm for? I want to delete them
|or move them to other filesystems (using symbolic links),
|but I don't know if it's harmless to do so. Could someone
|please give me advice? We use Solaris 2.6.
Do not delete the files in /var/sadm - they are the package & patch
database. Without them you cannot install any more packages or patches,
and will be forced to do a fresh install instead of upgrade if you ever
want to move to a newer version of Solaris.
--
________________________________________________________________________
Alan Coopersmith al...@alum.calberkeley.org
http://soar.Berkeley.EDU/~alanc/ aka: Alan.Coo...@Sun.COM
Working for, but definitely not speaking for, Sun Microsystems, Inc.
Kjetil Torgrim Homme
> furu...@ccsr.u-tokyo.ac.jp (Ryo Furue) writes in comp.unix.solaris:
> |Our /var often overflows (filesystem full). I noticed that
> |/var/sadm uses 62MB out of our small 192MB /var filesystem.
> |What are the files in /var/sadm for? I want to delete them
> |or move them to other filesystems (using symbolic links),
> |but I don't know if it's harmless to do so. Could someone
> |please give me advice? We use Solaris 2.6.
>
> Do not delete the files in /var/sadm - they are the package &
> patch database. Without them you cannot install any more packages
> or patches, and will be forced to do a fresh install instead of
> upgrade if you ever want to move to a newer version of Solaris.
It's moderately safe to delete
/var/sadm/pkg/PACKAGENAME/save/PATCHID
but if you do, you will no longer be able to backout that patch.
Kjetil T.
Phil Eschallier
> /var/sadm/pkg/PACKAGENAME/save/PATCHID
> Kjetil T.
At the risk of getting flamed for being commerical, we actually have a
software package which cleans up old Solaris patches as well removing
duplicated patch history data. It works on Solaris 2.4 thru 8.
--
Phil Eschallier
Bux Technical Services
70 Irish Meetinghouse Rd
Perkasie, PA 18944
215.249.TECH (215.249.8324)
215.249.8325 (fax)
http://www.BuxTech.Com
Mathew Kirsch
> Our /var often overflows (filesystem full). I noticed that
> /var/sadm uses 62MB out of our small 192MB /var filesystem.
> What are the files in /var/sadm for? I want to delete them
> or move them to other filesystems (using symbolic links),
> but I don't know if it's harmless to do so. Could someone
> please give me advice? We use Solaris 2.6.
I'd like to applaud you for actually asking before deleting files. There are
many so-called admins that would simply have said, "Oh, I'll just delete this
big fat /usr/lib directory and get myself some free space." Then they'd whine
about their box being broken shortly thereafter, "OHGODITSBROKE HELP HELP HELP
HELP!"
No, do not move or delete /var/sadm. It's the patch and package database that
tells the system what's installed on it.
Instead, you need to identify WHAT is filling up /var and WHY it's filling up
/var. Then you need to fix the problem. Post your reason(s) for wanting to
delete /var/sadm, what makes you think you need to do this, and people can
advise you about what you should do to eliminate the REAL problem.
All you're going to do by freeing up more space is postpone the inevitable.
/var will simply take longer to fill up, but it will still fill up.
Scott MacKay
>
> Ryo Furue wrote:
>
> > Our /var often overflows (filesystem full). I noticed that
> > /var/sadm uses 62MB out of our small 192MB /var filesystem.
>
> I'd like to applaud you for actually asking before deleting files. There are
> many so-called admins that would simply have said, "Oh, I'll just delete this
> big fat /usr/lib directory and get myself some free space." Then they'd whine
> about their box being broken shortly thereafter, "OHGODITSBROKE HELP HELP HELP
> HELP!"
burnt down :)
> No, do not move or delete /var/sadm. It's the patch and package database that
> tells the system what's installed on it.
the new location. Make sure you use a relative path for the link,
though, and that it is a location accessible if you need to be in single
user mode.
> Instead, you need to identify WHAT is filling up /var and WHY it's filling up
> /var. Then you need to fix the problem. Post your reason(s) for wanting to
> delete /var/sadm, what makes you think you need to do this, and people can
> advise you about what you should do to eliminate the REAL problem.
Agreed. Depending on your services, it could be a bad print queue, mail,
etc.
I would suggest doing a:
du -sk /var/*
df -k /var/mail
df -k /var/spool
See which directories report huge disk usage. It can help narrow down
which service is causing you problems.
--
-----
"This posting reflects the views of the poster and does not reflect the
views of the company."
Kevin W. Thomas
Mathew Kirsch <900...@corpmail.kodak.com> wrote:
>Ryo Furue wrote:
>
>> Our /var often overflows (filesystem full). I noticed that
>> /var/sadm uses 62MB out of our small 192MB /var filesystem.
>> What are the files in /var/sadm for? I want to delete them
>> or move them to other filesystems (using symbolic links),
>> but I don't know if it's harmless to do so. Could someone
>> please give me advice? We use Solaris 2.6.
>
>I'd like to applaud you for actually asking before deleting files. There are
>many so-called admins that would simply have said, "Oh, I'll just delete this
>big fat /usr/lib directory and get myself some free space." Then they'd whine
>about their box being broken shortly thereafter, "OHGODITSBROKE HELP HELP HELP
>HELP!"
>
>No, do not move or delete /var/sadm. It's the patch and package database that
>tells the system what's installed on it.
You *can* move /var/sadm, you just need to be careful. Here are the steps.
o Use "tar" to make a copy of /var/sadm somewhere else. For the purposes
of this example, lets call the new home /export/sadm.
o mv /var/sadm /var/sadm_old
o ln -s /export/sadm /var/sadm
o showrev -p
This last step is to confirm that "showrev" can really read the data files.
If it can't, you've done something wrong.
At your convenience, remove /var/sadm_old. To be on the safe side, you might
want to go ahead and back this up before deleting it.
I've been doing this for a long time on Solaris 2.6 systems that are out in the
field, and can't be rebuilt to increase the size of /var.
Just remember, if you apply patches in single user mode, be sure to manually
mount the true location of /var/sadm.
>Instead, you need to identify WHAT is filling up /var and WHY it's filling up
>/var. Then you need to fix the problem. Post your reason(s) for wanting to
>delete /var/sadm, what makes you think you need to do this, and people can
>advise you about what you should do to eliminate the REAL problem.
The problem is that there are a *lot* of patches with hundreds of small files
that add up to lots of disk space.
>All you're going to do by freeing up more space is postpone the inevitable.
>/var will simply take longer to fill up, but it will still fill up.
Another solution is to rebuild the workstation. With "jumpstart" this is
easy to do, though not always practical.
Kevin W. Thomas
Sun System Administrator & Meteorologist
Norman, Oklahoma
Email: kw...@swbell.net
Udo Beckmann
Hello,
check for files named undo.Z. These files are needed to backout patches.
You can delete these files if you don't plan to backout the corresponding
patch. On my system I regulary run
find /var/sadm -name undo.Z -mtime +60 -exec rm {} \;
Some additonal logfiles can also be deleted. But they are much smaller than
the undo.Z's. It's not worth the effort
Best Regards
Udo
Ryo Furue
Mathew Kirsch <kir...@kodak.com> wrote in message news:<3B21063D...@kodak.com>...
> Ryo Furue wrote:
>
> > Our /var often overflows (filesystem full). I noticed that
> > /var/sadm uses 62MB out of our small 192MB /var filesystem.
> > What are the files in /var/sadm for? I want to delete them
[...]
> I'd like to applaud you for actually asking before deleting files. There are
> many so-called admins that would simply have said, "Oh, I'll just delete this
> big fat /usr/lib directory and get myself some free space." Then they'd whine
> about their box being broken shortly thereafter, "OHGODITSBROKE HELP HELP HELP
> HELP!"
Yeah, I once did that. I renamed libc.so, and suddenly almost
every command stopped working! Obviously I learned the lesson :-)
> No, do not move or delete /var/sadm. It's the patch and package database that
> tells the system what's installed on it.
Thank you for telling that.
> Instead, you need to identify WHAT is filling up /var and WHY it's filling up
> /var. Then you need to fix the problem. Post your reason(s) for wanting to
> delete /var/sadm, what makes you think you need to do this, and people can
> advise you about what you should do to eliminate the REAL problem.
In fact, I knew what was filling up /var . An application converting
PostScript files to GIFs was using a lot of space in /var/tmp.
My opinion is that 192MB of /var is too small in the modern standard.
Some applications use /var/tmp/ by default, and users expect they can
handle some 100MB of data very easily.
It was actually my mistake that I didn't ask the vendor to customize the
partitioning of the system disk when we bought the machine. Since our
home directories are on another machine, we didn't need /export/home, and
we should have had a /var of 1GB instead of 192MB.
> All you're going to do by freeing up more space is postpone the inevitable.
> /var will simply take longer to fill up, but it will still fill up.
You are right with respect to log files and such things.
But, for workspace (/var/tmp/), 192MB is simply too small.
So, I'll perhaps move /var/tmp to another filesystem and will
create a symlink from /var/ to there. (I should have thought
of this before thinking of moving /var/sadm :)
Thank you anyway,
Ryo
Mathew Kirsch
> /var will simply take longer to fill up, but it will still fill up.
>
> You are right with respect to log files and such things.
> But, for workspace (/var/tmp/), 192MB is simply too small.
> So, I'll perhaps move /var/tmp to another filesystem and will
> create a symlink from /var/ to there. (I should have thought
> of this before thinking of moving /var/sadm :)
O I C.
You could take that leftover /export/home and re-mount it as /var/tmp. Then
you'd have plenty of scratch space for your application.
Kjetil Torgrim Homme
> You are right with respect to log files and such things.
> But, for workspace (/var/tmp/), 192MB is simply too small.
> So, I'll perhaps move /var/tmp to another filesystem and will
> create a symlink from /var/ to there. (I should have thought
> of this before thinking of moving /var/sadm :)
If you have plenty of swap, consider putting a tmpfs on /var/tmp as
well as on /tmp.
mount -F tmpfs swap /var/tmp
or even
mount -F tmpfs -o size=512m swap /var/tmp
You can also make /var/tmp a symlink to /tmp. /var/tmp is
traditionally persistent across reboots, but I doubt there are many
applications which rely on that. (vi's recovery mode kind of does.)
Kjetil T.
Ryo Furue
> In article <3B21063D...@kodak.com>,
> Mathew Kirsch <900...@corpmail.kodak.com> wrote:
> >Ryo Furue wrote:
> >
> >> Our /var often overflows (filesystem full). I noticed that
> >> /var/sadm uses 62MB out of our small 192MB /var filesystem.
> >> What are the files in /var/sadm for? I want to delete them
> >> or move them to other filesystems (using symbolic links),
> You *can* move /var/sadm, you just need to be careful. Here are the steps.
>
> o Use "tar" to make a copy of /var/sadm somewhere else. For the purposes
> of this example, lets call the new home /export/sadm.
>
> o mv /var/sadm /var/sadm_old
>
> o ln -s /export/sadm /var/sadm
>
> o showrev -p
>
> This last step is to confirm that "showrev" can really read the data files.
> If it can't, you've done something wrong.
>
> At your convenience, remove /var/sadm_old. To be on the safe side, you might
> want to go ahead and back this up before deleting it.
Thank you, Kevin! This worked for me, too!
Recently I applied a series of patches, which made it necessary
to move /var/sadm.
Ryo
Casper H.S. Dik - Network Security Engineer
kwth...@adsl-65-67-249-217.dsl.okcyok.swbell.net (Kevin W. Thomas) writes:
>You *can* move /var/sadm, you just need to be careful. Here are the steps.
>o Use "tar" to make a copy of /var/sadm somewhere else. For the purposes
> of this example, lets call the new home /export/sadm.
>o mv /var/sadm /var/sadm_old
>o ln -s /export/sadm /var/sadm
Oops, not careful enough. You're now no longer able to upgrade your
system; use:
ln -s ../export/sadm /var
(It must be a relative link for upgrade to continue to work)
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
Thomas Krickstadt
>> ln -s /export/sadm /var/sadm
> Oops, not careful enough. You're now no longer able to upgrade
> your system; use:
> ln -s ../export/sadm /var
> (It must be a relative link for upgrade to continue to work)
Why does make this a difference ? I always wonder, why there
are relative symbolic links instead of absolute ones, e.g.
'/etc/hosts -> ./inet/hosts', in Solaris ?
Kind regards, Thomas
--
Thomas Krickstadt, Siemens AG, Siemensdamm 50, 13629 Berlin, Germany
Phone : +49-30-386-28331, E-Mail : thomas.kric...@sietec.de
Alan Coopersmith
|Casper H.S. Dik wrote ...
|>> ln -s /export/sadm /var/sadm
|> Oops, not careful enough. You're now no longer able to upgrade
|> your system; use:
|> ln -s ../export/sadm /var
|> (It must be a relative link for upgrade to continue to work)
|
|Why does make this a difference ? I always wonder, why there
|are relative symbolic links instead of absolute ones, e.g.
|'/etc/hosts -> ./inet/hosts', in Solaris ?
When you boot off a different device (cdrom or network image) to do the
upgrade, your filesystems won't be mounted as / but under /a or /mnt,
and then only relative links will still work - absolute links will
point to the new filesystem.