>> 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
>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.
Quote:>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.
Quote:>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