Running out of space in /var/tmp when unpacking a patch

[John Walker_1]

I am trying to unpack a patch using:
sh PHSS_XXXX.
The patch is quite large and the process keeps filling up /var/tmp and therefore fails.
I have set TMPDIR to a large filesystem as recommended in the shar man page but it is still using /var/tmp.

How can I get it to use another directory to do its background stuff?

[Borislav Perkov]

Hi,
You can download the patch including the create_depot_hp-ux_11 script and you can make patch depot wherever you want.
Regards,
Borislav

[Borislav Perkov]

I mean you go to
http://www.itrc.hp.com/service/patch/
find the needed patch. Select it and click on download bottom not on downloading only the patch.

[Borislav Perkov]

Sorry here is the link:

http://www4.itrc.hp.com/service/patch/crumbRequest.do?crumb=patch.breadcrumb.main&BC=

[John Walker_1]

I really could do without downloading a 150Mb patch again if I can avoid it.

Is there no way I can get shar to use a filesystem other than /var/tmp?

[Morten Kristiansen]

What about rename /var/tmp to /var/tmp2 and then make a softlink which links /var/tmp to a large filesystem. After installing the patch, remove the softlink and rename /var/tmp2 to /var/tmp.

[Borislav Perkov]

It is strange anyway here is how you can install any patch.
Please follow this procedure.
1. Back up your system before installing a patch.

2. Login as root.

3. Copy the patch to the /tmp directory.

4. Move to the /tmp directory and unshar the patch:

cd /tmp
sh PHSS_XXXX

5. Run swinstall to install the patch:

swinstall -x autoreboot=true -x patch_match_target=true \
-s /tmp/PHSS_XXXX.depot

By default swinstall will archive the original software in /var/adm/sw/save/PHSS_XXXX. If you do not wish to retain a copy of the original software, include the patch_save_files option in the swinstall command above:

-x patch_save_files=false

WARNING: If patch_save_files is false when a patch is installed,the patch cannot be deinstalled. Please be careful when using this feature.

For future reference, the contents of the PHSS_XXXX.text file is available in the product readme:

swlist -l product -a readme -d @ /tmp/PHSS_XXXX.depot

I think this is solution for your problem.

Regards,
Borislav

[MarkSyder]

Is /var/tmp in a filesystem of its own or part of /var? If part of /var, how big is the filesystem?

What I'm getting at is, housekeeping on /var might free up enough space.

Mark Syder (like the drink but spelt different)

[Borislav Perkov]

Also consider that /usr/tmp directory is linked to /var/tmp directory.
Maybe you can try deleting some older files in /var/tmp:

as an example deleting all files which are modified for more than for days:

cd /var/tmp
find . -name '*' -mtime +4 -print -exec rm {} \;

[Pete Randall]

I'm with Mark. Housekeeping or simply temporarily moving something large out of /var could easily free up the required space. Take a look at what occupies the most space:

du -sk /var/* |sort -n

Then go through that list looking for something that you can temporarily move to another file system.


Pete

[Bill Hassell]

/var should be very large (several Gb) as it holds very dynamic directories for logs, emil, spooling and temp files. The simplest way is to create a new mountpoint for /var/adm/sw since this is always a large directory that is only used for install/unistall (software depot maintenance) tasks. Start by looking at the distribution of space in /var:

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

Now if you find some directory that is larger than /var/adm/sw, that is a potential location for trimming files (not always, but check the contents). Check the size of /var/adm/sw (the du -k output shows Kbytes) and create an lvol about twice as big. cd to the /var/adm/sw directory and copy all the files to the new lvol. Then create a new mounpoint in /etc/fstab. NOTE: this can all be done without a reboot or single user mode. Just make sure no other root user is running a software or patch install.


lvcreate -L 900 -m 1 vg03
newfs /dev/vg03/lvolXX
mkdir /mnt1
mount /dev/vg03/lvolXX
cd /var/adm/sw
find .|cpio -pudlmv /mnt1

To verify file and directory counts, use find and wc:

find /var/adm/sw -type f|wc -l
find /var/adm/sw -type d|wc -l
find /mnt1 -type f|wc -l
find /mnt1 -type d|wc -l
(the above counts should match except -type d will be one larger for the lost+found directory in the new mountpoint)


umount /mnt1
vi /etc/fstab

(add a new mountpoint from /dev/vg03/lvolXX to /var/adm/sw)

At this point, nothing has changed on the system except to make and verify a copy of the /var/adm/sw directory. Now remove all the files in the old directory: rm -r /var/adm/sw/* (be sure to use .../sw/* so you remove everything except the sw directory). Now mount the new location:

mount /var/adm/sw
bdf /var /var/adm/sw

Now /var should be several hundred megs smaller and /var/adm/sw should be about 50% used. Now the above procedure should be good for a long time as patches will make /var/adm/sw grow. You can now unpack patches in /var/tmp. If the patch set is large, I will unpack them in another directory. shar only uses TMPDIR when building the shar package. You can unshar the package anywhere as well as run swinstall against the .depot file anywhere. /var is only used for interim installation files and /var/adm/sw is used to hold the old files so that patches can be removed if needed.

[John Walker_1]

/var/tmp is its own filesystem and there is nothing in there to housekeep unfortunately.

It is only 100mb in size which clearly isnt big enough to unshar a 150Mb patch.

I am assuming that it uses /var/tmp during the unpacking process as a kind of holding area before it puts the unpacked patches in the directory where I want them.

I would extend /var/tmp but being a production machine this is difficult since it is constantly in use by one process or another

[Bill Hassell]

/var/tmp is way too small for a typical system as it is defined as the primary application temp directory. 1000 megs would be more appropriate and you will find even more limitations in the future. A single 150 meg patch is nothing compared to your next installation of the quarterly patch bundle (typically 300 megs). Even if you unpack the patch in another directory, swinstall may need some space in /var/tmp during the install. I would place expansion of /var/tmp at the top of your adamin project list.

[Bob_Vance]

>Is there no way I can get shar to use a
>filesystem other than /var/tmp?

You should note that the problem, here, is that the shell, 'sh', does not honor TMPDIR.
Sure, 'shar' does, but when you "unshar" it, you are simply using 'sh' -- *not* 'shar'.

The reason that /var/tmp is being used is because the HP patch files use the "here-document" ( "<<" ). As noted in 'man sh-posix', here-documents use /var/tmp by default, and if it is not accessible for some reason, it uses /tmp.

At one time in the past, in a Galaxy far away, with small disk drives, I wrote a little C program to "decode" the HP patch files and send to STDOUT, thus bypassing 'sh' and its temp file. I could make the decoded depot go anywhere :>)

However, recently HP has changed the encoding and broke my program. Happily disk space is rarely a problem these days with huge disk drives being the norm now, so I never updated my program.


The bottom line:

. unsharing HP patches always uses /var/tmp (well, rarely sometimes /tmp ;>).

. as stated by previous posters, you will need to increase free space in /var/tmp


bv