root file system full/removal of large files from root

[Julian Snype]

Hello everyone
I need some assistance with removing files from my root directory, which is currently at 100% capacity. I have read through many of the threads, which has provided me with lots of things to check. Now I need to know what should I do to get these large files out of root. Some of my problems are contributed to my knowledge (still learning). Listed are the large files that I found in root. I looked at the date stamp of the files in some of the directories since I have an idea when the problem occurred and the size of these files increased dramatically on this date. The other mounts are in fairly good shape with the exception of /opt.
Please see attachment for more detail.

Thanks
Julian

OSHP-UX 11i vi
Workstation j5000

Error message…
Message received msgcnt 106 vxfs: msg 001: vx_nospace - /dev/root file system full(1 block extent)

#bdf
File system kbytes used avail %used mounted on
/dev/vg00/lvol3 143360 143360 0 100% /
/dev/vg00/lvol6 897024 809970 81632 91% /opt
All other mounts are under 46% or less

du –kx | sort –rn | head -20
141437 .
93123 ./dev
93109 ./dev/rmt
24889 ./sbin
10835 ./etc
8449 ./etc/opt
6509 ./etc/opt/resmon
5817 ./sbin/fs
3454 ./sbin/fs/vxfs
3430 ./etc/opt/resmon/lbin

#du –t vxfs | sort –rnk 1 | pg (listed are the top 5)
3476000 .
1602274 ./opt
1396740 ./usr
702952 ./usr/lib
547670 ./opt/gnome


If I can get these files removed from root I may be in fairly good shape. What I don’t know is how do I remove these files without causing myself further damage. Is it a set of commands/procedure that I should follow to get them off? I don’t want to make the problem worst by removing something that I shouldn’t also should I use failsafe? .

#1
/ Core is very large - 11826572 bytes (what is the process for moving this off of root since it is a system file)

#2
/etc/dev - there are multiple files of the same kind that were all created the same time and date (can I removed these files/how can I remove)
“ crw------ 1 root root 31 0x00000f May 26 19:23 tun1 through tun79
“ crw------ 1 root root 31 0x000080 May 26 19:23 tunip0 through tunip15
#3
. btmp - 4560 bytes
. wtmp - 399900 bytes
. vtdaemonlog - 282200 bytes
. ps_data 18352 bytes
. ptydaemonlog 24133 bytes


#4
/dev/rmt
-rw------- 1 root sys 95334400 May 25th 1M( can this be removed?)


As you can see I have some problems and I'm really in need of your help.

[Florian Heigl (new acc) · Accepted solution]

As I'm quite tired I'll stick with the most obvious parts.
Thanks for the wonderful amount of information You gave!


Please do an ls -l on both the large files below so You have information about their generation time. maybe it's been months ago.

93109 ./dev/rmt
- it would appear something tried to write to a nonexistant tape device file.
It's /dev/rmt/1M - the device file is called /dev/rmt/1m - just a typo I figure.

/ Core is very large - 11826572 bytes
- if we're talking about a file named 'core' in / then it's an application core dump.
use the command
file /core
to find out which applicated terminated and wrote a core dump.

then use cp -p /core /var/adm/crash
and *overwrite* it using
> /core # the ">" is intentional :)

I don't think You need to save away the file in /dev/rmt, so simply use
> /dev/rmt/1M

after this You should have freed a healthy amount of space and can continue looking into the root issue with Your root :)

use fuser -uc /dev/rmt/1M to check if it's still accessed by a -probably stuck- process and use the same with /core

if this prints out no user ID You can now delete the files with rm, otherwise don't, but use ps -ef | grep $pid to find the relevant process's name.

I'd suggest You come back with that information.

Oh, btw:
1. Ignore Your tun devices and such, while You most probably never need any of them they don't use up a notable amount of disk space (the whole /dev on a normal host will be like 200k)

2.
#du t vxfs | sort rnk 1 | pg (listed are the top 5)
3476000 .
1602274 ./opt
1396740 ./usr
702952 ./usr/lib
547670 ./opt/gnome

forget about that: du -t vxfs would usually be used to look for local filesystems as opposed to CIFS or NFS mounted ones, it does not care about filesystem boundaries.

3. as people tend do it when they run out of space, I'll rather tell You in advance:
never move /usr/lib if You can avoid it, it tends to break things and generate a lot more coredumps.

[AwadheshPandey]

See attached document.
what to do if file system is full.

Cheers,
Awadhesh

[Torsten.]

Hi,

I'm quite sure, somebody tried to write to a tape, but by accident he took the wrong file.

correct:

/dev/rmt/1m

wrong:

/dev/rmt/1M

Because this tape does not exist, the backup was written to a file.

Save the file to a tape and delete it from the directory.

The /core file is created by an crashing application. Take a look at the file date and try

# file /core

to get a clue where it came from. Anyway, if you need this file for analyzing, you can move it to another directory.

[Julian Snype]

Thanks everyone for your responses and documents. With your assistance I was able to perform some additional analysis, make a few system adjustments and fix my root space problem. I can honestly say that I got to the root of the problem. My root file space is now at 28%.

Thanks again
Julian

[Julian Snype]

roos space problem was resolved