/usr filling up

[GREGORY JONES_3]

if /usr is 100% full in 11.00 will system crash or hang?

[Rick Garland]

That depends on what you have in /usr or what is mounting to /usr.

[TwoProc]

You need to fix it - but it's probably not going to shut you down. Man pages won't generate from compressed file if needed. You won't be able to patch your system, or add new commands from swinstall. But that's about it from what I can see.

[Pete Randall]

Usually /usr is relative static and growth is minimal if any. Are you actually seeing growth or is it just close to 100%? If there is a little slow growth, you should have time to schedule a little downtime to fix the problem.


Pete

[Florian Heigl (new acc)]

the system should run w/o larger problems arising from a full /usr.

an exception would be if there are applications that write logfiles or temporary data there (none should)

out of my head I could think of squid which is often installed to /usr/local/squid and usually dumps core when the cache_dir is full. same might be valid for /opt (stm and apache would log there) so You'd see application failures, but the OS should be safe.

always take care to give larger applications a filesystem of their own. i.e. a database application would stop working in an unhealthy state when it can't commit both data and redo logs...

also, You won't be able to extend a filesystem using OnlineJFS when it is 100% full, so having a 1MB dummy file in a known location can be helpful.

[Hoang Chi Cong_1]

Depend on the application that was installed on /usr. If there is any app was installed on it, it will cause any error.
You need to make a plan to encrease the /usr mount point system.
To enlarge this mount point, you have to boot in single-user mode.

Regard,
HoangChiCong

[Bill Hassell]

As with all computer systems, active managment of disk space is a requirement for system administrators. If you are using the default values for /usr (and /opt and /var and /tmp) and your system has growing usage, most all of these may have to be increased, doubled or tripled in size in most cases.

A problem application may be storing a log file somewhere in /usr (not the right place) or you have simply loaded a lot of applications that don't use the recommended location /opt, so /usr is filling up. Start by analyzing the biggest DIRECTORIES:

du -kx /usr | sort -rn | more

On a new 11i installation with a full set of patches and some common applications, this is what /usr looks like:

1406784 /usr
769472 /usr/lib
337232 /usr/lib/nls
288856 /usr/lib/nls/loc
169144 /usr/lib/X11
145112 /usr/lib/X11/fonts
141416 /usr/lib/nls/loc/pa20_64
138408 /usr/share
138184 /usr/lib/nls/loc/pa20_64/locales.2
119960 /usr/lib/nls/loc/locales.2
115984 /usr/share/man
112632 /usr/lib/X11/fonts/TrueType
111816 /usr/sbin
107552 /usr/dt

The units of measure are Kbytes so this /usr occupies about 1.5Gb of space. If you make /usr, /opt and /var all 2Gb, you should be fairly safe for the near future. But a regular task (which should be done by a cron job) is to monitor the percentage of use for the mounted filesystems (hint: bdf)

[GREGORY JONES_3]

thx for all you responses.
very helpful i will fix the problem by
scheduling down time to increase /usr.
only can add up to 20% more space, out of disk.

thx again

[Kent Ostby]

You're main trouble spots are going to be if /tmp or /var get filled up since important (but temporary files get generated in these file systems).

When cleaning up /usr, you can also use:

find . -size +1000000c -print

This will locate files that are greater than a meg big and might show you if you have something that is erroneously filling up the file system.

[Rory R Hammond]

/usr is pretty STATIC

try
cd /usr
find . -mtime -5 -print |wc

If it is a high number
you might

find . -mtime -5 -print |pg

to see what files are being added or changed
On one of my systems the number is 5
that is 5 files and they were man pages.
If you get bunch. you might have your system
miss configured. and the file names should give you a clue about what needs done

Good Luck
Rory