File system always FULL

[Kenn Chen]

my unix N4000 running openmail system. for past few weeks, the fs /var/opt/openmail always full and there is no other process is running. do you have any idea to trace it ??

[linuxfan]

Hi,

Did you try fuser to see if there are any process using the filesystem?
fuser -cu /var/opt/openmail should do it.
Also try running df/bdf/du -ks. Do you see a lot of discrepency (du is expected to generate a different result than the other two)

Another tool you can try using is lsof.

Also can you try unmounting and mounting the filesystem back again?

-HTH
I am RU

[Sridhar Bhaskarla]

Check how your spool directory is configured. For ex., the default sendmail directory is /var/spool/mqueue. If you spool directory is under /var/opt/openmail (I didn't work with openmail), keep a track of this directory. If by any chance, the mail is undelivered, it will wait in the queue. Such mails may eventually fill up if not cleared.

-Sri

[Bill Hassell]

/var/opt/openmail contains the data directory (/var/opt/openmail/data) which is the message store for all user messages. Assuming typical email users, there are probably megabytes of useless, oudated messages in user mailboxes. Time to clean house.

But first, check the size of all the directories in /var/opt/openmail. (I am making a assumption that /var/opt/openmail is a separate mounpoint). Summarize all the big directories with:

du -kx /var/opt/openmail | sort -rn | more

If the data directory is the largest in the chain, then get a bigger disk or chastise users about not cleaning up their mailboxes. Another step is to limit the maximum size of messages the can be received (ie, reject any message larger than 10 megs for instance)

If the largest directory is not data, then move into the big directory and see what's up. If nothing jumps out like a big file, list the directory in size order:

ll | sort -rnk5 | more

The biggest files will be at the top of the list. Note that any directory can be full (and remain full) with no special processes running.

[linuxfan]

Hi,

Frankly i have never used openmail, but the document id A5740417 talks about a filesystem (/var/opt/openmail) being full.

/Begin/
Problem Description

I am running Online JFS (Journaled File System). The syslog file
contains the following message:

vxfs: mesg 001: vx_nospace /dev/vg01/lvol1 filesystem full
(8 block extents).

The filesystem in question (/var/opt/openmail) is a 2 GB filesystem.
/var/opt/openmail contains 500 MB of free space.

How do I resolve this problem?

Configuration Info

Operating System - HP-UX
Version - 10.20
Hardware System - HP9000
Series - K460
Subsystem - Online JFS

Solution

You can use one of two methods to resolve your problem:

Method 1:

A. Backup the /var/opt/openmail filesystem.

B. Execute the newfs command on the /var/opt/openmail filesystem.

C. Restore the data from the /var/opt/openmail filesystem.

Note: Method 1 is the recommended procedure. This method is faster
and easier.

--OR--

Method 2:

A. Add more free contiguous space to the /var/opt/openmail
filesystem.

B. Defragment the /var/opt/openmail filesystem.


/End/

Idris, are the symptoms you are seeing on your system the same as described in this document?

Anyone who has used openmail, are these the only options available?


-Regards
I am RU

[Jim Turner]

Hi Idris,

I only have a little to add to Bill's sensible answer. Assuming that users' directories are in /var/opt/openmail/data, you can find the major space hogs thus:

du -kxs /var/opt/openmail/data/* | sort -rn | more

The results will be shown in kilobytes and will be summarized by directory under /var/opt/openmail/data. Then you can send nasty-grams to the top ten or so space hogs and tell them that they can clean up their mail, or *you* can clean up their mail -- their choice. I find that adding an overtone of mental instabibility when sending such a message is a wonderful motivator for users.

All the best,
Jim

[Jim Turner]

"instabibility"? Jeez, I shouldn't get so liquored-up before posting to the forums
;-)

[unixdaddy]

you can run omscan (check the man pages) to get a list of the worst offenders. You can then use omtidyuall (clears up all users, again check the man pages) or omtidyu (for a specfic user).

Use mailq to check mailq and check the openmail logs - /var/opt/openmail/logs to see if any errors are report.

[Dave Kelly_1]

One of the first things that we recommend in a case like this is to check the Item Structure Server logs in /var/opt/openmail/structlog.

These files are only ever useful if you are using the Single User Restore functionality. Chances are that you are not.

1) Stop the Item Structure Server

omoff -d 0 -a "Item Structure Server"

2) Clean out the files

rm /var/opt/openmail/structlog/*

3) [ONLY DO THIS IF YOU ARE SURE YOU DON'T WANT TO USE THE SINGLE USER RESTORE]
Prevent the Item Structure Server daemon from starting again.

omsetsvc -i "Item Structure Server"