The purpose of this paper is to inform you about what the cleanup command is and how it works on HP-UX 10.x. The cleanup command will "clean up" patch related areas.
Such as, removal of superseded patches in /var/adm/sw/patch, trimming of SD-UX logfiles, removal of superseded patches in a depot and clean the IPD (Installed Products Database). The cleanup command was originally released in patch PHCO_5400. However, new features were added to the command which in turn, caused PHCO_5400 to be superseded by PHCO_12140. So, the latest version of cleanup is version 2 and it is delivered in PHCO_12140.
PATCHING MECHANICS, BEHIND THE SCENE.
Prior to delving into the specifics of the cleanup command, an overview of what happens behind the scenes may be helpful. In the following example, watch how things change as newer versions of /sbin/mount are installed. The newer versions of /sbin/mount, in this example, are delivered in patches PHCO_1234 and PHCO_5678. These two patches are fictitious and are used for example purposes only.
1. HP-UX 10.20 prior to any patches for /sbin/mount.
# what /sbin/mount
/sbin/mount:
$Revision: 78.9 $
|
2. After PHCO_1234 is installed, which is a patch for /sbin/mount.
# what /sbin/mount
/sbin/mount:
$Revision: 78.9.1.1 $
# pwd
/var/adm/sw/patch
# ll
drwxr-xr-x 2 root sys 1024 Apr 11 17:47 .SUPERSEDED
-rw-r--r-- 1 root sys 4377 May 5 11:30 PATCH.log
drwxr-xr-x 4 root sys 1024 Feb 26 13:48 PHCO_1234
|
Notice, in figure 2, how /sbin/mount has a new revision number and see what was created under /var/adm/sw/patch directory. There are more directories under /var/adm/sw/patch/PHCO_1234. If you drill down this directory you will ultimately find the original mount command, revision 78.9. Everything under /var/adm/sw/patch/PHCO_1234 is there just in case you need to remove PHCO_1234 from the system. This is where swremove will find the previous revision of mount.
3. After PHCO_5678 is installed, which is also a patch for /sbin/mount and supersedes PHCO_1234.
# what /sbin/mount
/sbin/mount:
$Revision: 78.9.1.2
# pwd
/var/adm/sw/patch
# ll
drwxr-xr-x 2 root sys 1024 May 5 13:59 %PHKL_1234
drwxr-xr-x 2 root sys 1024 Apr 11 17:47 .SUPERSEDED
-rw-r--r-- 1 root sys 4377 May 5 11:30 PATCH.log
drwxr-xr-x 4 root sys 1024 Feb 26 13:48 PHCO_5678
#
|
Again, notice how /sbin/mount has a new revision number and see what other directories were created under the /var/adm/sw/patch directory. The significance of the example is the percent sign in front of PHCO_1234. This percent sign denotes that this patch has been superseded. At this point, in this example, there are three versions of mount (see figure 4). The chances of ever needing to get back to the original revision of mount is very small. Therefore, any patch directory under /var/adm/sw/patch that starts with a percent sign is a directory that contains binaries and/or files that have been superseded at least twice.
/sbin/mount Revision 78.9.1.2
/var/adm/sw/patch/PHCO_5678/usr/sbin/mount Revision 78.9.1.1
/var/adm/sw/patch/%PHCO_1234/usr/sbin/mount Revision 78.9
|
So, the more patches you apply to your system, the more "stuff" you are keeping under /var/adm/sw/patch. Please note that the files under individual patch names, i.e. PHCO_5678 are not the binaries and files for that particular patch. The files here are for the potential removal of that particular patch. Therefore, underneath PHCO_5678, you would find the files for removal of PHCO_5678. These include the scripts necessary to actually remove that patch and the binaries that were on the system before the patch was installed.
SD-UX LOGFILES.
Also, as a by product of using SD-UX commands, information is written to command specific logfiles. All of the logfiles (SD-UX), are located in the /var/adm/sw directory. For instance, information from the swinstall command will be logged to /var/adm/sw/swinstall.log. These logfiles can become quite large over time.
# pwd
/var/adm/sw
# ll *.log
-rw-r--r-- 1 root sys 368417 May 5 11:32 swagent.log
-rw-r--r-- 1 root sys 73559 May 5 11:32 swagentd.log
-rw-r--r-- 1 root root 41419 Mar 4 15:06 swconfig.log
-rw-r--r-- 1 root sys 83087 Mar 30 17:21 swcopy.log
-rw-r--r-- 1 root sys 52356 May 5 11:30 swinstall.log
-rw-r--r-- 1 root root 113042 May 5 11:30 swmodify.log
-rw-r--r-- 1 root sys 2506 Mar 23 14:11 swreg.log
-rw-r--r-- 1 root sys 12501 Apr 23 09:19 swremove.log
-rw-r--r-- 1 root sys 518 Mar 9 09:52 swverify.log
|
OPTIONS OF THE CLEANUP COMMAND
.-t This option is for trimming the logfiles. It will reduce all of the SD logfiles to the last five iterations.
-F This will force removal of all patch directories under /var/adm/sw/patch. You will have more disk space after running this options. However, you will not be able removes any patches that are currently running on your system.
Blank This option is probably the most common, it is simply running the cleanup command with no options. First this will trim your logfiles. This is the same as the -t option. The command will prompt you before trimming just in case you do not want to trim. Secondly, it will remove the binaries and possibly the directories that start with a percent sign under /var/adm/sw/patch.
-i This option is for syncing the IPD (Installed Products Database).
-d This option is for removing superseded patches from a depot.
TRIMMING THE LOGFILES
When you run the cleanup command with no options or the –F option, you will be prompted to see if you want the logfiles trimmed to the last five entries. And if you reply yes, they will be trimmed. Also, if you just want to trim the logfiles, you can use the –t option. Of course it is always a good idea to store these logfiles to tape before trimming them.
# cleanup -t
This is the HP-PATCH disc space recovery tool. It will automatically
recover disc space for you that is being used for backup of original
files that have been patched. As an added feature, if you like, your
SD log files can also be trimmed.
Trimming SD log files
Trimming swagent.log
Trimming swagentd.log
Trimming swconfig.log
Trimming swcopy.log
Trimming swinstall.log
Trimming swmodify.log
Trimming swreg.log
Trimming swremove.log
Trimming swverify.log
#
|
REMOVING OLDER, SUPERSEDED PATCH FILES.
To remove older, superseded patches, i.e. the superseded patch directories that start with a percent (%) sign, see figure 3, run the cleanup command with no options. As always, it is a good idea to back things up prior to removing them from the system. See the note regarding backuplist in figure 7. Also, this option will trim the SDUX logfiles at your discretion.
# cleanup
This is the HP-PATCH disc space recovery tool. It will automatically
recover disc space for you that is being used for backup of original
files that have been patched. As an added feature, if you like, your
SD log files can also be trimmed.
The log files for SD can get very large. Would
you like the logs trimmed to the last 5 entries? > n
The following patch backups are marked for removal :
%PHCO_10589 %PHCO_10964 %PHCO_11462 %PHCO_11585 %PHCO_11982
|
|
Only the patches in /var/adm/sw/patch with a percent sign (%)
will appear here.
It is highly recommended that you backup the directory '/var/adm/sw/patch'
before removing a large portion of its contents. If you have not done
so, you may wish to reconsider completing this operation.
NOTE: If you backup the '/var/adm/sw/patch' directory, use the list of files
in '/var/adm/sw/patch/backuplist' as the list of files to backup.
Continue with removal? > y
>>>> Removed backup directory: %PHCO_10589 05/05/98 15:40:59
>>>> Removed backup directory: %PHCO_10964 05/05/98 15:40:59
>>>> Removed backup directory: %PHCO_11462 05/05/98 15:40:59
|
|
Only the patches in /var/adm/sw/patch with a percent sign (%)
will appear here.
Backup removal complete.
The results of this action have been logged to:
'/var/adm/sw/patch/PATCH.log'.
|
REMOVING ALL SUPERSEDED PATCH INFORMATION
This option of cleanup will remove all of the files required to remove a patch from you system. In other words, you will NOT be able to swremove any of the patches on your system after running the cleanup command with the –F option. The benefit of this option is that you will have more space in /var. The trade off is that you cannot remove any of the patches that are currently on your system. This option works like running the cleanup command with no option. The only difference is that it will remove all patch directories under /var/adm/sw/patch, not just those with the percent sign. Also, the –F option will give you a warning about not being able to back out any patches after running the command.
CLEANING UP A DEPOT.
To help understand the purpose of this option, you must first understand the concept of depots and the potential problem that can occur after adding new patches to a depot.
A depot, actually in this case a directory depot, is just a collection of patches. It is where multiple patches exist together for the purpose of being available to be swinstalled on multiple boxes. You would have a depot for each different version of HP-UX that you support. The following steps show a normal progression of a depot.
When patches are added to a depot for the second time, or anytime thereafter, there is a chance that some of the new patches just added replace older patches that are already in the depot. Following are two examples of situations that could occur in a depot where both a new and old version of a patch exists.
Example 1: Depot with PHCO_5555 and PHCO_8888 (these patch numbers are made up for this example). Both of these patches patch the same binary. When swinstall is executed using this depot, the checkinstall script is executed for each of the patches in the depot. In this example, both 5555 and 8888 will be approved for installation. This happens because at the time checkinstall is executed, neither 5555 nor 8888 is installed. Therefore swinstall will install both patches. A depot is really just a directory and directories are sorted lexically. Therefore, 5555 will go in first and 8888 will go in second. After swinstall completes, if swlist is executed to show what patches are on the system, both 5555 and 8888 will appear as installed. This is actually false information, as 5555 is not truly installed. This information is misleading but not typically detrimental because 8888 is the newer version of the patch.
Example 2: Depot with PHCO_7777 and PHCO_11111 (these patch numbers are made up for this example). Both of these patches patch the same binary. When swinstall is executed using this depot, the checkinstall script is executed for each of the patches in the depot. In this example, both 7777 and 11111 will be approved for installation. This happens because at the time checkinstall is executed, neither 7777 or 11111 is installed. Therefore swinstall will install both patches. A depot is really just a directory and directories are sorted lexically. Since these patches are in lexical order, PHCO_1 comes before PHCO_7. Therefore, 11111 will go in first and 7777 will go in
second. After swinstall completes, if swlist is executed to show what patches are on the system, both 7777 and 11111 will appear as installed. This is actually false information as 11111 is not truly installed. This situation is worse in comparison to the first example. The swlist will show you that 11111, the latest version of the patch is installed and it is not installed because 7777 was installed after it. Again, the "acid test" to determine what version is installed is to do a what on the binary and compare it the what string in the patch text file.
Therefore, you should always "clean up" your depot after adding more patches to it. To do this, you would run the cleanup command with the –d option. On the next page, in figure 8, there is an example of cleaning a patch depot. Also, when you use the –d option, it does not touch any other patch information outside of the depot that you are running it on. It does not touch the binaries that are currently installed, it does not touch the IPD (installed products database) and it does not do anything with the files under /var/adm/sw/patch.
# cleanup -d /patch/prod.depot
This utility will locate all patches in the depot '/patch/prod.depot'
that have been superseded by patches also available from this depot.
After identifying the superseded patches, it will request confirmation
before removing the patches from the depot.
Obtaining the list of superseded patches in the depot...
The following patches in the depot have been superseded by patches
also in the same depot.
Superseded Patch Replacement Patch(es)
---------------- ---------------------
PHCO_11004 PHCO_11315
PHCO_8677 PHCO_11586
PHKL_9711 PHKL_11471
PHNE_10511 PHNE_11051
Hit [Return] to continue...
Would you like to continue with the process to remove these
superseded patches from the depot? y
In addition to the superseded patches listed, there may also be
patches in the depot that have corequisite attributes
(hard-coded dependencies) on one or more of the superseded patches.
Patches with corequisites are typically from the HP-UX Extension
Software. If these patches exist in the depot, they will also need
to be removed to maintain the integrity of the depot.
Now checking for patches with corequisite attributes set for one or
more superseded patches. Please be patient, this may take several
minutes.
No other patches were found in the depot that have corequisite
attributes set for superseded patches targetted for removal.
Do you wish to continue with the removal of the superseded patches
from the depot? y
Please be patient, this may take several minutes.
Removing patches from the depot...done!
The superseded patches have been removed from '/patch/prod.depot'.
#
|
CLEANING UP THE IPD.
The IPD, Installed Products Database, is made up of many files under the /var/adm/sw/products directory. At 10.x, SD (Software Distributor) considers patches as products. Therefore, when a patch is installed, information is recorded in the IPD. Under certain circumstances, the IPD can get out of sync with what is really on the box. Specifically, when you have a system at 10.01 or 10.10 and you have patches on the box. If you upgrade to 10.20, again, upgrade not install, the patch information will still reside in the IPD. At that point the IPD is not in sync with what you have on the box. To correct this, run cleanup (see figure 9). This scenario can also happen when you reinstall a product on your system after the original product was patched. Also, if you restore from a backup tape and that backup tape was made prior to having patches on the system, the potential is there for the IPD to be out of sync.
# cleanup -i
This utility will identify the patches that have been overwritten by
the installation of software products during an upgrade or install
process. Once the patches are identified, it will request confirmation
before removing the patch information from the SD-UX Installed Product
Database.
Obtaining the list of installed products and patches... done!
Comparing installed product and patches information...
All the patches in the SD-UX Installed Product Database
appear to be installed.
No action is required.
|
cleanup man page
cleanup - HP-UX patch cleanup utility
Synopsis:
cleanup [-F]|[-t]|[-i]|[-d absolute_path_to_depot]
DESCRIPTION:
The cleanupp command provides several functions useful when dealing
with HP-UX patches. It is used as an aid in managing disk space
consumed by the storage of backup files during the installation of a
patch. The cleanup command is also used to remove patch information
from the SD-UX Installed Product Database (IPD) after patches have
been overwritten by software updates. The cleanup command provides an
additional option to remove patches from a software depot if they have
been superseded by newer patches also available in the same depot.
Another feature of cleanup is its ability to trim the SD log files
located in /var/adm/sw/sw*.log.
No file removal will occur without user confirmation.
There are 5 modes of operation for cleanup
|