Help - Root folder at 92%
oracle1:$> df -k
Filesystemkbytesusedavail capacity Mounted on
/dev/dsk/c0t0d0s01800369 1592733 15362592%/
/proc 0000%/proc
fd 0000%/dev/fd
mnttab 0000%/etc/mnttab
swap142260840 14225681%/var/run
swap14257363168 14225681%/tmp
/dev/md/dsk/d28705501 627674 79907728%/u03
/dev/md/dsk/d048379179 41453292 644209687%/u01
/dev/md/dsk/d333041555 25984014 672712680%/u05
/dev/md/dsk/d157081545 24263383 3224734743%/u02
/dev/md/dsk/d615485063 13580275 174993889%/u07
/dev/md/dsk/d56195027 1476165 465691225%/u04
/dev/md/dsk/d88060691 110534 78695512%/u06
/dev/dsk/c0t0d0s76359393 2987302 330849848%/export/home
We don't have a dedicated Solaris Admin to help us with this problem, so I am appealing to all the Solaris Gurus out there.
I have tried to remove any unwanted files, but the "/" is still growing. How do I expand the disk space?
The "/" is mounted on a separate disk. Can I replace this disk or add another slice to it, without breaking anything?
What are my other options and how do I accomplish?
Thanks in advance.
[1149 byte] By [
PROfessora] at [2007-11-26 17:32:11]
# 1
What applications do you run on the node? Oracle I assume? Do you use apache?The problem is most likely in /varDo a 揷d /var?and then a 揹u 杒?br>It is most likely a log file that does not auto rotate.
HvRa at 2007-7-9 0:00:11 >
# 2
Which is exactly why /var should _always_ be on a separate slice on the disk./tony
# 3
amen
HvRa at 2007-7-9 0:00:11 >
# 4
> Which is exactly why /var should _always_ be on a> separate slice on the disk.Why?-- Darren
# 5
Yes, we do use apache?What logs should I be looking for? There are so many folders here.
# 6
If you use Apache shipped with Solaris check the following log file sizes:
ls -alsn /var/apache/logs/access_log
ls -alsn /var/apache/logs/error_log
ls -alsn /var/apache2/logs/access_log
ls -alsn /var/apache2/logs/error_log
but 1st make sure the problem is in /var
run a du -k /var check the size. (run it as root)
HvRa at 2007-7-9 0:00:11 >
# 7
/var should always be separate in a critical server/workstation since it's possible for a task to runaway and completely fill /var with logs. It's better to just have /var filled, than / filled!
# 8
Take care if you have not placed backup accidently. Check the the size of utmpx/wtmpx in /var/adm/ directory. They somethimes get too large.
If you can not find any large files, there might be a case that you had copied any large file in any directory like u01 before mounting it. So the data would be on / but would not be visisble. It is better to ask someone near you who knows Solaris if system is critical.
I am not a Sun Engineer!
# 9
Thank you, the access_log and error_log were huge.I truncated it.
# 10
What is wtmpx in /var/adm ? It is 176MB.If I know what this is, I can probably trim it down.
# 11
Logon info, reboot, connection info etc. is kept in the file.
Command 搇ast?will probably display 1000s of lines.
To clean-up on a live system, copy the file to alocation where it will get sent to tape (keep at least for a good few months, you might need some info from it.)
cp -p /var/adm/wtmpx /mount_point_with_lots_space/wtmpx.2008-02-08
cat /dev/null > /var/adm/wtmpx
You will now recover that space.
HvRa at 2007-7-9 0:00:11 >
# 12
> /var should always be separate in a critical
> server/workstation since it's possible for a task to
> runaway and completely fill /var with logs. It's
> better to just have /var filled, than / filled!
I guess I don't see the big difference. Either way, logging is going to stop. You have to clean it up. The machine doesn't crash just because root is full. How does the separation improve the machines availability or uptime?
I see *FAR* more people that mis-size / and /var and then want to change things than I have ever seen have a problem filling root (and have it cause a problem) with logs.
--
Darren
# 13
If "/" is full, users can't do work at all. If "/var" is full, logging breaks, but users can continue working until you fix the problem. If it's a single user machine there's no big difference, but on a mission-critical multi-user system it's a world of difference! (I had a runaway lpd process completely fill /var overnight one time, so I know what I'm talking about :-) ).
# 15
Just as a by-the-way, jDiskReport from www.jgoodies.com is a very nice, small,GUI tool for finding large files, large directories, old files, and so on.
# 16
What type of "work" broke when your root was full? We've run several production servers with unified / filesystems. There were a couple of instances where root filled, but I don't remember anything tragic occuring.
The only thing I remember complaints about was vi not opening files because it couldn't make copies in /var. So that behaves the same.
--
Darren
# 17
Well, if there's no room where users are trying to save files, and they want to save files it becomes tragic (especially when there's no IT people on duty at the time)!
# 18
I wasn't really considering user/application space, only the OS areas (/, /usr, /var, /opt, etc...). User/application data would always be separate, although often for the opposite reason (you don't want the users or the apps to remove all space for the OS).
So yes, I'd agree that /export or whatever application space is used should be separate from from root. That doesn't really affect whether or not you want /opt, /usr, or /var to be separate from root.
--
Darren
