SUMMARY: what's filling /var? Oracle sockets?

From: John Christian <john.christian_at_TheCReGroup.com>
Date: Thu May 05 2005 - 11:32:20 EDT
Darren nailed it first:

> # lsof +D /var
>
> That command is probably useless because it's explicitly
> looking for  files in the /var  directory.  If they were
> still in the directory, they'd appear in 'du'.  You need
> files that aren't in the directory.
>
> Try '+aL1 /var' instead.

# lsof +aL1 /var
COMMAND PID USER   FD   TYPE DEVICE    SIZE/OFF NLINK NODE NAME
auditd  342 root    5u  VREG  32,11 16407638005     0 5447 /var
(/dev/dsk/c1t0d0s3)

So, man auditd leads me to man audit which leads me to this interesting snip:
     -n    Signal audit daemon to close the  current  audit  file
           and  open a new audit file in the current audit direc-
           tory.

# audit -n
# df -ha | grep var
/dev/dsk/c1t0d0s3       17G    66M    17G     1%    /var
swap                    43G    16K    43G     1%    /var/run

Thanks everyone!
-John Christian


________________________________

From: sunmanagers-bounces@sunmanagers.org on behalf of John Christian
Sent: Thu 5/5/2005 10:47 AM
To: sunmanagers@sunmanagers.org
Subject: what's filling /var? Oracle sockets?



Hello,

/var is filling up. df reports 15-G used while du reports 62-Megabytes used.
I'm familiar with this type of discrepancy and I've typically taken the easy
route and rebooted. I don't have that luxury this time.

lsof for /var reports the usual suspects syslogd, cron, and sendmail. I've
stopped these processes, checked their log files (which are very small), and
started them up. That should clear any open files they might have right?

lsof for /var also reports 3 oracle-related sockets. Could these sockets be
counting against space for /var? Should I ask the DBA to restart these
processes instead of doing a full reboot?

What else am I missing? Any other suggestions on reclaiming /var?


# df -ha | grep var
/dev/dsk/c1t0d0s3       17G    15G   1.8G    90%    /var
swap                    43G    16K    43G     1%    /var/run

# du -sh /var
  62M   /var

# lsof +D /var
COMMAND    PID   USER   FD   TYPE DEVICE SIZE/OFF NODE NAME
ocssd.bin  390 oracle   11u  unix  105,7      0t0  636
/devices/pseudo/tl@0:ticots->/var/tmp/.oracle/sOracle_CSS_LclLstnr_localhost_
0
(0x30004c61c88) (Vnode=0x30004c68ab8)
tnslsnr    487 oracle   10u  unix  105,8      0t0  636
/devices/pseudo/tl@0:ticots->/var/tmp/.oracle/s#487.1 (0x30004c61ac0)
(Vnode=0x30008527800)
tnslsnr    487 oracle   11u  unix  105,9      0t0  636
/devices/pseudo/tl@0:ticots->/var/tmp/.oracle/sEXTPROC (0x30004c618f8)
(Vnode=0x30009633e28)
syslogd   8335   root  cwd   VDIR  32,11      512   95 /var/log
syslogd   8335   root    4w  VREG  32,11     3569 5435 /var/adm/messages
syslogd   8335   root    6w  VREG  32,11     3569 5435 /var/adm/messages
syslogd   8335   root    7w  VREG  32,11     4013  118 /var/log/authlog
cron      8368   root  cwd   VDIR  32,11      512  106 /var/spool/cron/atjobs
cron      8368   root    1w  VREG  32,11     4577 5043 /var/cron/log
cron      8368   root    2w  VREG  32,11     4577 5043 /var/cron/log
sendmail  8386   root  cwd   VDIR  32,11      512 3835 /var/spool/mqueue

TIA!
-John Christian
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
_______________________________________________
sunmanagers mailing list
sunmanagers@sunmanagers.org
http://www.sunmanagers.org/mailman/listinfo/sunmanagers
Received on Thu May 5 11:40:08 2005

This archive was generated by hypermail 2.1.8 : Thu Mar 03 2016 - 06:43:46 EST