/opt full

[brian_31]

Hi:

We have on our production box /opt as full. This is a new Lclass box which went live this weekend. we have 2G for /opt. pl. help??? what would be the issue???

Thanks

Brian

[Colin Topliss · Accepted solution]

Have a look in the /opt filesystem for anything updated recently (around the timeframe of the message).

Perhaps you have an application there which is writing log files to that filesystem?

[Marco Santerre]

Have you checked for any core files under all su-directories of /opt?

Also check for any software that you may not need. You amy also want to check for log files that are under /opt and put them somewhere else like /var

[Shannon Petry]

Lets see what's in /opt....


What does the following command produce for output? (Note: "%" is the prompt)

% cd /opt
% du -sk *


Paste the output here please.

Shannon

[Tom Danzig]

If you have OnlineJFS and some free space in you root volume group, you could extend it on the fly.

If you don't have OnlineJFS, you would most likely need to be in single user mode to do so. lsof could tell you what processes had /opt open. You would have to shut down the Measureware daemons and distributed print services at a minimum.

If there is no rome to extend in the root VG, you'll have to increase it via Ignite/UX or user swremove to clean out any unused installed software.

[S.K. Chan]

The /opt houses applications and you may need to check each of them that were installed to find out if any temporary files are created in them. The standard (usually) for log files are to be located in /var/opt/ but you'll never know, check them anyway. Look for core files ...
# find /opt -type f -name core -exec ll {} \;
Look for files that are recently created (use -mtime option in find). Look for big files ..(example bigger than 2MB)
# find /opt -type f -size +2000000c -print
If still can't spot anything run ..
# cd /opt
# du -kx *|sort -rn > /tmp/test
# more /tmp/test
That should give you some idea how the dirs/files are distributed.

[Brian M Rawlings]

The /opt FS is normally used for applications and utilities, etc, things other than official OS binaries and utilities. It needs to be sized according to the requirements of whatever SW you load on top of the OS.

If you do a 'du -k /opt' > /tmp/du.out', you will be able to page through the /tmp/du.out file to see which files and directories are taking up how much space (see the man page for 'du' if you aren't familiar). Hopefully you can tell from file and directory names which apps (or other items) are taking up more space than you planned for.

By convention, things in /opt should not grow, once installed. Logs and output files should be sent to the '/var' file system instead. It may be that some poorly written or incorrectly installed app or utility is writing logs or output somewhere in /opt. Or, somebody recently loaded some new SW, and filled up /opt.

If you can't find any logs or obvious culprits, you might try using the 'find' command to do a 'long listing' of all files in /opt. Then look at the timestamp (date and time) in the long listing to see which files were most recently added. This has to be taken with a grain of salt, however, because files can be moved from another location with their timestamps intact.

If new SW has just filled up /opt, it will simply need to be resized upwards to a size that is more suitable. One way to do this is to use the ignite/ux 'make_tape_recovery' utility to create a bootable image of your root volume group on tape, then boot from that tape and restore everything to the boot disk, with an interactive session that lets you specify new sizes for root file systems.

Alternatively, you could just reboot in single user mode, and grow /opt with 'lvextend' and 'extendfs'. Whichever way you go, search through the forums for examples, there are tons of them for both cases.

Regards, --bmr

[Steven E. Protter]

Since /opt is not a critical filesystem like /var, it should not be necessary to go to single user mode to extend it.

You can do everything except extendfs -F vxfs /dev/vg00/lvol# (whichever one is opt) after unmounting it.

I have the exact same allocation as you to /opt and am barely past half full, so look at what you installed and see if a large data file or depot accidently landed there.

SEP

[Bill Hassell]

Unless you have installed a MASSIVE number of applications, 2Gb is more than enough space for /opt. So the likely culprit is in just one directory...but it is not likely to be a big file, just a bunch of unnecessary files.

So find the biggest directories. As mentioned, use du to summarize each subdirectory, but add a sort to the output so you can see the biggest first:

du -kx /opt | sort -rn | more

Now look at the top of the list. Most likely there will be oddball application or very non-standard directory at the top. Here's a somewhat normal 11.0 /opt:

1099964 /opt
198518 /opt/ignite
152122 /opt/perf
141506 /opt/hpapache2
128430 /opt/ignite/boot
122450 /opt/langtools
66500 /opt/ids
63306 /opt/perl
54760 /opt/perl/lib

Note that ignite is by far the largest, followed by perf. But they are only 100-200 megs in size. If you something else larger, the directory needs scrutiny. You can use:

ll -rnk5 /whatever | more

[Sunil Sharma_1]

Hi,

have a look into /opt/tmp directory, if size of this is too big u can clean it.

Sunil

[Bill Hassell]

I would not create an /opt/tmp directory. The only proper locations for a temp directory are /tmp and /var/tmp. /opt is relatively static in size, growing only when you add applications. Data created by those applications should never go into /opt.

[bob folsom]

Hi Brian. Do the following, and compare the output

bdf /opt
cd /
du -skx /opt

If the output from the du command is greatly differnet that what bdf shows is being used, someone removed an open file. If this is what happened, the only way to realcaim the space is to kill the process that has the open file (this can be determined with lsof), or a reboot if all else fails. . .