vmunix: /usr: write failed, file system is full

[Bruno Vilardo]

Hello All,

I have checked the /var/adm/messages file and inside it it shows :

Mar 21 04:47:03 dasscws1 vmunix: /usr: write failed, file system is full.

What can i do to clean up this File System.

Thanks a lot
Bruno

[Ralf Puchner · Accepted solution]

Bruno,

why not checking what file leads to filesystem full. If var is within /usr check /var/adm/log and /var/adm/crash first.

[Bruno Vilardo]

Thanks Ralf ,.


I have many log files at /var/adm/
Is it normal ?

Thanks
Bruno

[Ralf Puchner]

yes, if you are in doubt:

# apropos

to get an explanation for the specific file.

[Michael Schulte zur Sur]

Hi,

please post
df -k
cd /var/adm;du -ks *

/var/adm/syslog.dated can also become large.

greetings,

Michael

[Bruno Vilardo]

Hello ,

Here is the output of df -k :

df -k
Filesystem 1024-blocks Used Available Capacity Mounted on
root_domain#root 512000 223110 276816 45% /
/proc 0 0 0 100% /proc
usr_domain#usr 6326760 5513843 812917 88% /usr
poa_db#db_prod 19491992 8830463 10631552 46% /db_prod
poa_bi#bi_prod 10378280 5915777 4450736 58% /bi_prod
poa_dump#dump_load 19186744 14380561 4763256 76% /dump_load

and here is the output of /var/adm du -ks *

2 BRscqad1_10_26_00.log
392 BRscqad1_11_08_00.html
2 BRscqad1_11_08_00.log
1164 acct
0 best1_6.3
0 best1_6.5
0 best1_default
1920 binary.errlog
2 btcreate.log
47 crash
61 cron
26 defragcron.log
1 diskdiag
32 dms
0 eng02_err
0 fee
32 lastlog
31 lmf
16 log.1v2zh31
3 log.291l441
6 log.310014013
1 log.4epqy
13 log.4epro
8 log.50163099sp
51 log.50163099sp.old
1 log.5kzrv01
8 log.5x2zh31
7 log.62y1201
1 log.6347hfg40751
5 log.6403hfg40104
1 log.6403hfg40224
3 log.6d1ckfkzv157
1 log.6d1ckfkzv15f
32 log.6d1ckfkzv1ac
4 log.6d1ckfkzv1bw
3 log.6gyih
36 log.73jdy21
5 log.7p4nj01
16 log.7t2zh31
6 log.8j18501
10 log.8p4nj01
16 log.9w2z431
8 log.9ypft31
2 log.alevrius!
6 log.brad8303641
5 log.brat8301731
48 log.bv2zh31
24 log.c9mk441
8 log.cad01
52 log.cad01.old
40 log.cad02
10 log.cp4nj01
0 log.cpq13643498548
1 log.d2lssg41
1 log.dasgrfs1
1 log.daspafs1
1 log.dasscws2
8 log.dc5k931
1 log.dkcl001
7 log.dktr01
2 log.f004cknj1169
1 log.f102fvy10070
8 log.f284bpl40247
6 log.f537hpu20207
3 log.f547htb20280
12 log.f548htb21257
32 log.f639231
16 log.f639bbd20170
26 log.f705hvt31480
13 log.f716hvt50230
24 log.f716hvt50265
3 log.f726hvt30130
9 log.f726hvt30162
9 log.f731bbd21266
4 log.f733hvu50426
0 log.f733hvu53656
5 log.f735hvu50532
0 log.f745bk521964
7 log.f745bk522817
18 log.f814bk622915
9 log.f826bnt50149
24 log.f913bw3r1000
32 log.f913bw3r1001
6 log.f913bw3r1002
12 log.f913bw3r1003
9 log.f913bw3r1004
6 log.f913bw3r1005
8 log.f913bw3r1006
16 log.f913bw3r1009
11 log.f913bw3r1010
6 log.f913bw3r1011
19 log.f913bw3r1012
16 log.f913bw3r1013
6 log.f915bw3r1001
5 log.f923bw381054
21 log.f923bw381055
16 log.f923bw381059
9 log.f923bw381061
5 log.f923bw381064
7 log.f923bw381068
12 log.f923bw381070
10 log.f923bw381090
8 log.fl3xm
51 log.fl3xm.old
12 log.g639231
43 log.gustavo
51 log.gustavo.old
1 log.h9mk441
40 log.jx6q431
28 log.localhost
51 log.localhost.old
56 log.nmb
0 log.scsnbk027
0 log.scsnbk100
0 log.scswks038
0 log.scswks103
1 log.scswks315
0 log.scswks350
0 log.scswks370
1 log.scswks410
0 log.scswks430
0 log.serta01
40 log.smb
51 log.smb.old
1 log.v807bvp4j277
18 lp
0 lp10acct
0 lp10err
0 lp11acct
0 lp11err
0 lp12
0 lp12acct
0 lp12err
0 lp13acct
0 lp13err
0 lp14acct
0 lp14err
0 lp15acct
0 lp15err
0 lp16acct
0 lp16err
0 lp17err
8 lp18err
0 lp1acct
0 lp1err
0 lp2acct
1 lp2err
0 lp3acct
1232 lp3err
0 lp4acct
0 lp4err
0 lp5acct
0 lp5err
0 lp6acct
1 lp6err
0 lp7acct
0 lp7err
0 lp8acct
0 lp8err
0 lp9acct
0 lp9err
0 lpacct
0 lperr
1 messages
1 mountdtab
3568 pacct
18 patch
14 printcap.log
64 ris
308 sendmail
265 smlogs
9952 syslog
109 syslog.dated
9 sysman
13 utmp
57 wtmp
0 wtmp.ORI

Thanks Bruno

[Michael Schulte zur Sur]

Hi,

the logfiles are error files from your spool queues. lp3err is big, look what is in syslog. Did you already delete files?

Michael

[Johan Brusche]

The largest chunk of data seems to sit behind the syslog directory. Tru64 itself normally does not use that directory, because all standard syslogd output goes to the directories behind syslog.dated
So what is it in /etc/syslog.conf that sends so much data to the syslog directory.

If there is nothing that should send logging to /var/adm/syslog, the delete everything in there.

You should also regulary recycle the binary.errlog to keep its size below 1MB. Under V4.0G do this as follows:

cd /var/adm
mv binary.errlog binary.errlog.old
kill -HUP `cat /var/run/binlogd.pid`
gzip binary.errlog.old

The other large file (3MB) is the summary accouting file "pacct". Do you have ACCOUNTING=YES in /etc/rc.config ?

Johan.

[Michael Schulte zur Sur]

Bruno,

/var/adm did not have that much space used, however /usr has more than 5gb used. This is suspicciously high.

It would be nice, if you could post
du -k /usr
as attachment. Somewhere something is using enormously space.

thanks,

Michael

[Bruno Vilardo]

Michael,
No i havent deleted these files.


I checked the rc.config file and it doenst say ACCOUNTING =YES.


Thanks
Bruno