bdf result

[Sanjiv Sharma_1]

Hi,

I have a J6000 workstation/HP-UX 10.20.
#bdf
Filesystem kbytes used avail %used Mounted on
/dev/vg00/lvol3 139541 40471 85115 32% /
/dev/vg00/lvol1 83733 31686 43673 42% /stand
/dev/vg00/lvol8 1967605 1716272 54572 97% /var
/dev/vg00/lvol7 1601771 621868 819725 43% /usr
/dev/vg00/lvol4 1441109 182072 1114926 14% /tmp
/dev/vg00/lvol6 1025027 451710 470814 49% /opt
/dev/vg00/lvol5 6291456 1962370 4060884 33% /home

# du -k /var | sort -nr |more
347876 /var
294805 /var/adm
293736 /var/adm/sw
268157 /var/adm/sw/patch
26611 /var/opt
24968 /var/adm/sw/patch/PHSS_21454
24755 /var/adm/sw/patch/PHSS_21454/opt
24754 /var/adm/sw/patch/PHSS_21454/opt/graphics
22743 /var/adm/sw/products
..........................

bdf shows that /var filesystem is 1.9 GB and is 1.7 GB used i.e., 97% full. But the du shows that /var is 347 MB used.

I don't think there is 1.7 GB data in /var.

What needs to be done?

Thanks for your help.

[steven Burgess_2 · Accepted solution]

Hi Sanjiv

Looks to me like a file has been removed whilst a process was still writing to it. To free the space you will have to unmount /var and remount. This will have to be done in single user mode

You can do this remotely

shutdown -y 0

HTH

Steve

[Michael Tully]

You have a file(s) open (still in memory) that have been deleted. The only way the two will match (bdf & du) is when the process that carries the file(s) in memory are terminated.

Unless you can identify it you have a problem. Obviously a reboot will free this up, but it is not what you want.

Check the open processes using fuser and tools like 'lsof'

# fuser /var

Regards
Michael
"When I have trouble spelling, it's called fat finger syndrome"

[Patrick Wallek]

I agree that this sounds like a file that was being accessed at the time you removed it.

You do not necessarily have to umount /var to remedy this though. You simply need to figure what process is accessing the file that was removed and somehow stop that process.

Since the file was in /var my first inclination is that the file was in /var/stm/logs/sys and may have been the activity_log file. That file can grow quite large if a machine has problems and the diagnostic daemon starts writing messages to it.

If you want to try out this theory you can do a

# /sbin/init.d/diagnostic stop

and wait and see if the space gets freed up. If it doesn't it may be more difficult to figure out.

You can start by doing an

# fuser -cu /var

and see what all processes are accessing /var. Unfortunately the list may be quite long and the easiest option may be to reboot the machine.

Good luck.

[Con O'Kelly]

Hi

I have run into this problem a number of times and as has been stated above it is likely to be a result of deleting an open file.

As there seems to be a large descrepancy between the du & bdf output sizes, it should be possible to identify the offending file. Use lsof /var and look for any large files that could be culprits. Check if the file shows up when doing a normal ls -la on the directory. If not, then that it is likely to be your culprit. You will need to kill the process that is holding that file open, that should then free up the space.

Cheers
Con

[Steven E. Protter]

Best option in my opinion is to boot the box.

shutdown -ry now

If that is not possible,

fuser -cu /var can help you identify the process, if you can't figure it out, then fuser -cuk /var

the k stands for kill and will dump all users out of your system.

If you can't clear processes off the filesystem then you will not be able to umount /var

SEP