root dir is shown 97% full

[Kiruba]

ciscmc2:/auto_home/operALU1 $ bdf
Filesystem          kbytes    used   avail %used Mounted on
/dev/vg00/lvol3     262144  254235    7561   97% /
/dev/vg00/lvol1     255253   43579  198911   18% /stand
/dev/vg00/lvol8    17563648 2369634 14245430   14% /var
/dev/vg00/lvol9    8388608    3172 8123400    0% /var/adm/crash
/dev/vg00/lvol7    14286848 1756388 11747368   13% /usr
/dev/vg00/lvol16    393216   24894  345338    7% /usr/Systems/Global_Instance_7.1.2_Master
/dev/vg00/lvol17   2818048   81867 2565219    3% /usr/Systems/Global_Instance_7.1.2_Master/maintenance
/dev/vg00/lvol15   60227584 32645632 27399904   54% /usr/Systems/CMC_1_2.1_Master
/dev/vg00/lvol6    4915200  177398 4443332    4% /tmp
/dev/vg00/lvol5    20381696 6544722 12979374   34% /opt
/dev/vg00/lvol11    524288    1229  490375    0% /opt/tao1.4l_p7
/dev/vg00/lvol14    131072   61513   65218   49% /opt/JacORB2.1.3.5
/dev/vg00/lvol13   246677504 2855248 241929560    1% /ldaphome
/dev/vg00/lvol4    11141120  112491 10339361    1% /home
/dev/vg00/lvol10   4849664    7266 4539755    0% /alcatel
/dev/vg00/lvol12   15532032 12606032 2834612   82% /alcatel/7.1
/ldaphome          246677504 2855248 241929560    1% /auto_home

I tried to browse this HP-UX forum and solutions to check for core files,larger files did not help.

Did anyone face such issue.

A similar server with same configuration is having only 24%.

/var is a seperate lvol

[Patrick Wallek]

What does the following show?

# du -kx | sort -nr | head -10

This iwll give you the 10 largest directories under /.

You can the proceed in each of those to see what is the largest by cd'ing into each directory and then running 'du -ks * | sort -nr | head -10' to get the 10 largest.

[Dennis Handly]

>I tried to browse this HP-UX forum and solutions to check for core files, larger files did not help.

There should be many topics on what to search for next.

Large directories.  Files that were removed while open, etc.

>/var is a separate lvol

What about /tmp?

[Kiruba]

Thankyou for the response.

/tmp is a seperate lovl.

If i do a du-sk and check the size it is diffrent from the one shown by bdf(used).

I have done a ls -lar and seperated the dir& files which are really under "/" and which has a seperate lvol,kindly have a look.

ciscmc2:/ $ ls -lart
total 280
dr-xr-xr-x   2 root       root            96 Mar 12  2004 tmp_mnt ==> 0

-rwxr-xr-x   1 root       sys           5451 Mar 12  2004 .dtprofile

drwxrwxrwx   2 root       sys             96 Mar 15  2004 SD_CDROM

drwxr-xr-x   2 root       root            96 Sep  2  2010 lost+found



drwxr-xr-x   3 root       sys             96 Sep  2  2010 .secure
-rw-rw-rw-   1 root       sys           1155 Sep  2  2010 .profile.orig



-rw-r--r--   1 root       root            56 Sep  2  2010 .cshrc
-rwxrwxr-x   1 root       root          1195 Sep  2  2010 .profile

dr-xr-xr-x  18 bin        bin           3072 Sep  2  2010 sbin ==> 26058

drwxr-xr-x  16 root       sys           1024 Sep  2  2010 SCINSTALL ==> 8660



drwxr-xr-x   2 root       sys             96 Sep  3  2010 .mcc
drwx------   2 root       sys             96 Sep 14  2010 .ssh

-rwxrwxrwx   1 root       sys           8064 Oct 14  2011 dst.pl


-rw-r--r--   1 root       sys             10 May  3  2012 .mozilla-license
drwx------   3 root       sys             96 May  3  2012 .mozilla
drwxr-xr-x   2 root       sys             96 Jul  4  2012 .ethereal
-rw-r--r--   1 root       sys              0 Aug 30  2012 date
-rw-r--r--   1 root       sys              0 Aug 30  2012 tail
-rw-------   1 root       sys           1024 Oct 16  2012 .rnd
-rw-------   1 root       sys            447 Oct 18  2012 .Xauthority


-rw-r--r--   1 root       sys              4 May  8  2013 ns.pid
drwxr-xr-x   6 root       sys           1024 May 23 09:32 .sw



-rw-------   1 root       sys            679 Jun 25 13:10 .TTauthority
-rw-------   1 root       sys           5794 Jun 25 13:10 .ICEauthority
drwxr-xr-x  12 root       sys           1024 Jun 25 13:11 .dt
drwxr-xr-x   2 root       sys             96 Jun 25 17:27 .graphon
-rw-------   1 root       sys           8038 Jul  3 09:16 .history

-rw-r--r--   1 root       sys              0 Sep 24 16:41 cd

dr-xr-xr-x  15 bin        bin           6144 Oct 28 10:26 dev ==> 21

-rw-r-----   1 root       sys           4807 Oct 28 12:10 tteamlmc1-ux.20131028.1105.tar.gz

-rw-------   1 root       sys          20140 Nov  4 16:18 .sh_history

dr-xr-xr-x  34 bin        bin           9216 Nov  4 22:16 etc ==> 23413

drwxr-xr-x  27 root       root          2048 Nov  5 08:40 ..
drwxr-xr-x  27 root       root          2048 Nov  5 08:40 .

************************************************************************************************
lrwxr-xr-t   1 root       sys              8 Sep  2  2010 bin -> /usr/bin (lvol aval)
lrwxr-xr-t   1 root       sys              8 Sep  2  2010 lib -> /usr/lib (lvol aval)
lrwxrwxrwx   1 root       sys              5 Sep  2  2010 users -> /home (lvol aval)

lrwxr-xr-x   1 root       sys             19 Sep  2  2010 mirror -> /alcatel/MirrorArea(lvol aval)
lrwxr-xr-x   1 root       sys             19 Sep  2  2010 backup -> /alcatel/BackupArea(lvol aval)

dr-xr-xr-x  25 bin        bin           1024 Sep  2  2010 usr(lvol aval)

dr-xr-xr-x  98 bin        bin           3072 Apr 18  2012 opt(lvol aval)

drwxr-xr-x  12 root       root          1024 May  2  2013 alcatel(lvol aval)



drwxr-xr-x  77 imp_alu    cmc           8192 Jun  4 15:00 auto_home(lvol aval)

drwxr-xr-x  54 root       root          3072 Jun  4 15:00 home(lvol aval)

drwxr-xr-x  77 imp_alu    cmc           8192 Jun  4 15:00 ldaphome(lvol aval)


drwxrwxrwx  30 bin        bin           1024 Oct 16 10:16 var(lvol aval)
dr-xr-xr-x  11 bin        bin           1024 Oct 28 10:26 stand(lvol aval)

dr-xr-xr-x   1 root       root             1 Oct 28 10:26 net(no lvol aval,not in /)



drwxrwxrwx  20 bin        bin          26624 Nov  5 08:46 tmp(lvol aval)

 **********************************************************************************************************

ciscmc2,sys,root # du -xk . |sort -nr|head -20
60012   .
26058   ./sbin
23870   ./etc
11518   ./etc/opt
8660    ./SCINSTALL
7804    ./etc/opt/resmon
5859    ./sbin/fs
5034    ./SCINSTALL/scripts
3861    ./etc/opt/resmon/lbin
3487    ./sbin/fs/vxfs
2812    ./etc/opt/resmon/log
2148    ./etc/opt/cifsclient
2120    ./etc/opt/cifsclient/unitables
1755    ./sbin/fs/hfs
1222    ./.mozilla
1217    ./.mozilla/default/2nflcxxz.slt
1217    ./.mozilla/default
1017    ./etc/opt/resmon/lib
766     ./etc/lvmconf
608     ./sbin/init.d


ciscmc2,sys,root # cd net
ciscmc2,sys,root # bdf .
Filesystem          kbytes    used   avail %used Mounted on
-hosts                   0       0       0    0% /net
ciscmc2,sys,root #

[Kiruba]

Thanks for your feedback.

The issue is ,If i do a du-sk and check the size it is diffrent from the one shown by bdf(used).

[Bill Hassell]

With all the . files in /, it is obvious that root's $HOME directory is in the worst possible location, that is /. I know, HP (and IBM and Sun and Linux,...) all make / = root's home. But it is a terrible location for root's home. There are junk files, config files, a tar file, none of which belong in the / directory. Now these files are not causing the 97% full filesystem, but root's home needs to be moved. The other reason is that / is a very dangerous place to for root. A simple mistake can erase all the files in the system.

The important listing is the sorted du. It shows the occupied space is 60 MB, not 254 MB. A common error is to remove file(s) that are still being used. Unix is fairly friendly in that respect -- you remove the filename from the directory but the actual space is still being used. Once a program opens a file, the filename is no longer relevant and removing it from a directory does not affect the program.

So there is a program (or programs) that keep this invisible file open. Until these programs are stopped, the space is still in use. The best tool to use is lsof to find all the programs that are using the / filesystem.

[Kiruba]

We have tried a reboot of the server but still the same issue persist.

If there are any such open fiiles then it should have been solved by the reboot.

Do you have any idea

[Dennis Handly]

>We have tried a reboot of the server but still the same issue persist.

>If there are any such open files then it should have been solved by the reboot.

Yes, a reboot will usually finally remove that file.

Have you used lsof(1) to find that removed file?  A large file pointer value will indicate a large file.