How to cleanup an old patch

[NDO]

Hi

I have a system running hp-ux 11.31 that the following subdirectory is filling /var filsystem:

/var/adm/sw/save

So I have run the follwing command:

cleanup -p -c 1
### Cleanup program started at 01/02/18  16:06:42
Preview mode enabled. No modifications will be made.
Commit patches superseded at least 1 time(s) on 'dbnode0'.
Obtaining superseded patch information...done.

The following patches superseded at least 1 time(s) can be committed:

Superseded  # Times Superseded  Disk Space in /var/adm/sw/save  Superseded By
==========  ==================  ==============================  =============
PHCO_36126           1                    24576 bytes             PHCO_40087
PHCO_36481           1                   163840 bytes             PHCO_39367
PHCO_36525           1                   360448 bytes             PHCO_38608
PHCO_36539           1                   393216 bytes             PHCO_39042
PHCO_36841           1                        0 bytes             PHCO_40110
PHCO_37027           1                   434176 bytes             PHCO_39862
PHCO_37252           1                   540672 bytes             PHCO_38586
PHCO_37286           1                  2097152 bytes             PHCO_40123

PHSS_38157           1                 11321344 bytes             PHSS_40832
PHSS_38527           2                  5734400 bytes             PHSS_41099
PHSS_38568           2                  1441792 bytes             PHSS_39766
PHSS_39094           2                 57614336 bytes             PHSS_41492
PHSS_39100           1                  9560064 bytes             PHSS_41181
PHSS_39102           1                  1163264 bytes             PHSS_41496
PHSS_39122           1                 38797312 bytes             PHSS_40201
PHSS_39766           1                  9543680 bytes             PHSS_41775
PHSS_39876           1                 39895040 bytes             PHSS_41259
PHSS_41099           1                 10158080 bytes             PHSS_41423
PHSS_41492           1                 83910656 bytes             PHSS_42040

All information has been logged to /var/adm/cleanup.log.
### Cleanup program completed at 01/02/18  16:06:42

And that I run the :

 #tail /var/adm/cleanup.log
PHSS_39102           1                  1163264 bytes             PHSS_41496
PHSS_39122           1                 38797312 bytes             PHSS_40201
PHSS_39766           1                  9543680 bytes             PHSS_41775
PHSS_39876           1                 39895040 bytes             PHSS_41259
PHSS_41099           1                 10158080 bytes             PHSS_41423
PHSS_41492           1                 83910656 bytes             PHSS_42040

All information has been logged to /var/adm/cleanup.log.
### Cleanup program completed at 01/02/18  16:06:42

And now too sure if for example pacth PHSS_41496 is a replacement for old PHSS_39102.

If so how can I clean single patch of if its ok to clean/remove all superseeded patchs?

[pooderbill]

If you login to the HP Support Center, you can look up any patch and see the patch trees.

 Here's the top of the tree:

Patch tree

[NDO]

Hi

Thanks for the reply, I now understand that patch PHSS_39102 is older compared to PHSS_41496, but what I want to know is how to remove, using the "cleanup" command, or if I can remove "swremove" command

[Patrick Wallek]

You cannot remove a saved patch that has not been superseded by another patch.

If PHSS_41496 is the latest version, then it must remain so that it can be removed, if necessary.

Do not use 'swremove' as it will uninstall the patch, which is not what you want.

[Bill Hassell]

The cleanup command performs swremove for superceded patches, so you can use swremove for PHSS_39102 . It is not installed as PHSS_41496  is the current patch.  Good sysadmin practice would be to retain one level of superceded patches just in case a current patch must be rolled back.

I would be more concerned about the size of /var. It is one of the most critical mount points in the system. Appliations will fail, printing will stop, patches cannot be installed, etc when /var fills up. Your system is very unstable in this condition. If you cannot expand /var in your current configuration, I would use external disks and move the /var/adm/sw directory to a new mountpoint.

If you haven't done so yet, you can analyze the biggest directories with this command:

du -kx /var | sort -rn | head -20

The largest directories will be sorted to the top of the list. You may find an application has created thousands of small files in a directory which can be trimmed. Also, log files grow without bounds in the /var/adm directory. Use this command:

ll /var/adm | sort -rnk5 | head -10

to find the largest ones. Note that some log files are binary (wtmps, btmps) rather than ASCII and cannot be trimmed with vi or tail.

[NDO]

Hi Bill!

Thanks for the reply, I did run the command to find big directories and:

/var #du -kx /var | sort -rn | head -20
8706784 /var
4247216 /var/adm
3614688 /var/spool
3590112 /var/spool/cron
3589624 /var/spool/cron/tmp
2900056 /var/adm/sw
2497064 /var/adm/sw/save
938256  /var/adm/cron
534208  /var/opt
361600  /var/adm/syslog
325536  /var/adm/sw/save/PHCO_41192
325480  /var/adm/sw/save/PHCO_41192/VXVM-RUN
273312  /var/opt/psb
269504  /var/opt/psb/db/pgsql
269504  /var/opt/psb/db
208528  /var/adm/sw/save_custom
200040  /var/adm/sw/save_custom/PHCO_37694
184336  /var/adm/sw/products
167672  /var/opt/perf
165824  /var/opt/perf/datafiles

and inside /var/spool/cron/tmp, I found crout files:

/var/spool/cron/tmp #ls -lrt | tail
-rw-------   1 oracle     oinstall   37617226 Jan  4 08:51 croutYRN003559
-rw-------   1 oracle     oinstall   35536458 Jan  4 08:51 croutQHM003559
-rw-------   1 oracle     oinstall   38501962 Jan  4 08:51 croutODR003559
-rw-------   1 oracle     oinstall   38764106 Jan  4 08:51 croutZYJ003559
-rw-------   1 oracle     oinstall   38248010 Jan  4 08:51 croutVGW003559
-rw-------   1 oracle     oinstall   36486730 Jan  4 08:51 croutAFI003559
-rw-------   1 oracle     oinstall   38985290 Jan  4 08:51 croutSVE003559
-rw-------   1 oracle     oinstall   37027402 Jan  4 08:52 croutJNG003559
-rw-------   1 oracle     oinstall   39444042 Jan  4 08:52 croutRXH003559
-rw-------   1 oracle     oinstall   38903370 Jan  4 08:52 croutGCP003559

and the contents of one of the files does not make sense:

/var/spool/cron/tmp #more croutGCP003559
sed: Cannot find or open file zte_bscsix_retail_billing.txt.
rm: zte_bscsix_retail_billing.txt non-existent
ftp: connect: Connection timed out
ftp: connect: Connection timed out
ftp: connect: Connection timed out
ftp: connect: Connection timed out
ftp: connect: Connection timed out
ftp: connect: Connection timed out

Because that cron entry that is referred at the top of this crout file is commented in crontab!!

The number of files in this directory is always the same (115), but strange enough there is always new files (crout) in this directory.

The crout files have embeded on its name a PID, and when I do :

/var/spool/cron/tmp #ls -lrt | tail
-rw-------   1 oracle     oinstall   39812962 Jan  4 09:01 croutWNS003559
-rw-------   1 oracle     oinstall   39575394 Jan  4 09:01 croutZHJ003559
-rw-------   1 oracle     oinstall   39370594 Jan  4 09:01 croutGLO003559
-rw-------   1 oracle     oinstall   36880226 Jan  4 09:01 croutOUR003559
-rw-------   1 oracle     oinstall   37674850 Jan  4 09:01 croutPSO003559
-rw-------   1 oracle     oinstall   40107874 Jan  4 09:01 croutQIK003559
-rw-------   1 oracle     oinstall   36142946 Jan  4 09:01 croutTBD003559
-rw-------   1 oracle     oinstall   37330786 Jan  4 09:01 croutHIN003559
-rw-------   1 oracle     oinstall   38592354 Jan  4 09:01 croutKUC003559
-rw-------   1 oracle     oinstall   37527394 Jan  4 09:02 croutLAB003559
dbnode0[139]/var/spool/cron/tmp #ps -ef | grep 3559
    root  6531 19073  1 09:02:09 pts/2     0:00 grep 3559
dbnode0[140]/var/spool/cron/tmp #

nothing is shown.... I am not sure what is happening

[Bill Hassell]

So based on the directory summary:

3589624 /var/spool/cron/tmp

 and

2900056 /var/adm/sw

are the two bggest directories, representing more than half the used space in /var.

The situation for the cron directories needs attention, specifically for the oracle-owned cron jobs that are generating constant error messages. The PID shown in the crout files is accurate while the cron job is running but by the time you look for the PID, the job has already finished.. 

I would get your Oracle DBAs to look at this cron job and fix the issues. That will free up much more pace than removing superceded patches and risking no rollback level.