Is /usr/sbin/cleanup safe

[Darrell Tschakert]

Hi,
The logical volume that holds the /var filesystem on one of our HP 9000's is out of space - bdf shows 99% used. We feel that we can gain needed space from the /var/adm/sw/save directory by running /usr/sbin/cleanup. We are not, however, familiar with cleanup and are therefore reluctant to use it unless we are quite certain that it will not cause us problems later.

Does anyone have any horror stories that resulted from the use of cleanup? Any sad stories? Are there things that we should look out for when using cleanup? Any comments on cleanup. We plan to use the "-c 3" option the first time, just to see how it goes and to get familiar with cleanup - any comments on this reasoning.

We have twice backed up the /var/adm/sw to tape and then verified the tape as readable. We are aware that the man entery states "Recovering disk space should not be the only factor considered when committing patches." But, we have no choice and must have the space.

Thanks,

Darrell Tschakert
EEOC, Washington, DC

[Pete Randall]

Darrell,

It sounds to me like you're well aware of the potential hazards of removing old patches and you're proceeding very cautiously. Running cleanup with the "-c 3" option should be fine, though I'm not sure it will free much space.

Have you already gone through the log files and the du -sk /var* |sort -n routines to trim what you can and to find the worst offenders?

Pete

[James R. Ferguson]

Hi Darrell:

'cleanup' is definitely safe. In fact, it is the only sanctioned way to cleanse '/var/adm/sw'. 'cleanup' is a friendly front-end to 'swmodify'.

My preference is to preceed a patch session with 'cleanup -c 1' to form a new baseline of patches. If you prefer to be more conservative, change '-c 1' to -c 2'.

In addition to removing copies of superseded patches, 'cleanup' also trims the SD logs which also returns precious '/var' filesystem space.

Regards!

...JRF...

[Robert-Jan Goossens]

Hi,

Agree with Pete. There is an other option, moving a part off /var to a different filesystem.

http://forums.itrc.hp.com/cm/QuestionAnswer/1,,0xebe69200caded5118ff40090279cd0f9,00.html

Hope it helps.

Robert-Jan.

[James Odak]

i've never had a problem with it. Just make sure you are using the newest rev of cleanup (updated via, yes another patch heh)
under 11.x you run cleanup -p/n -c #
p is preview only
n is to notify changes and requres confirmation before running

# is the number of superceded patches to save, 1 being the lowest

ALSO
make sure you do not have any patches in the default depot of /var/spool/sw

This takes up a lot of space at times to0 and can easily be moved to any other directory besides /var

[Hai Nguyen_1]

Darrell,

I have used the cleanup command a few times. Trying "-c 3" is pretty safe since I even tried with "-c 2". However, I think that we should never try with "-c 1" since we may want to roll back a patch.

Run "du -sk /var/adm/sw" to be sure that this dir does occupy a lot of space. Also try to rotate your logs in /var/adm/syslog to minimize logs size. Remove files in /var/adm/crash if any.

Hai

[fg_1 · Accepted solution]

Darrell

We have used the -c3 option on our systems and it gained us back about an avg of 300-350MB of space in our filesystems, we did it using the -c2 option and gained about 200MB more than that.

I strongly agree with the previous contributors, I wouldn't use the -c1 option at all.

Gl

Frank G.

[John Payne_2]

I use cleanup -c 1. You may want to do a cleanup -p -c {1,2,3} to get a preview of what will be committed, etc. before you do it.

Here is the reason I use cleanup -c 1: Most of my servers are built off the same Ignite image. I install the QPK regularly, and test in R&D before migrating to stage and production in our environment. We have yet to run into an issue, and I run cleanup -c 1 before applying the next patch bundle, but regardless of this, if something gets screwed up, it takes about as long to reinstall a server as it does to back off the patches, reboot, check all the apps, etc. (I have yet to have to resort to reinstalling because of a patch problem... I do not expect that I will, either)

I keep multiple generations back of this image and have documented what is there. That way, if an issue ever comes up, I can go back to where I need to be.

The few issues that ever crop up are resolved in R&D before hitting the production servers, anyway.

Hope it helps

John

[Bob_Vance]

I use a combination of :

1. moving (copy and delete) /var/adm/sw to a larger filesystem/directory (say, "/larg/var_adm_sw ") and create a link to it
ln -s /larg/var_adm_sw /var/adm/sw

2. cleanup -c 1

NOTE -c 1 means commit patches that have been *superseded* *at least once*.

Thus you keep the current patch *and* the one preceding it (the one that has been superseded by the current).

You can still roll back the current patch once. However, very occasionally, this isn't enough :| , so the above-recommended -2 or -3 are safer.

bv

[Darrell Tschakert]

Folks,
Thank you for the replies. I have yet to get a negative report on cleanup as a result of my posting, so will will go ahead and use it today.

I am very behind now so I will assign points later.

Thanks,
Darrell Tschakert

[Darrell Tschakert]

Folks,
OK, we ran "cleanup -c 3" and got about 430 Mag of free space. "cleanup -c2 -p" says that well get another 350 Meg. This is pretty close to what we had hoped for and expected. Having gotten the good recommendations helped a lot so I thank you all. Most of the answers were clear, helpful, and to the point. We had considered copying the /var/adm/sw/save directory elsewhere and then linking to it, but once we got the confidence in cleanup we felt that it was the best way to go.

Thank you,
Darrell Tschakert

[John Payne_2]

You should post to Dan's ITRC forums successes page. They like to hear about this kind of thing. (I think it helps them justify the extra expenses to maintain the forums...)

John