sendmail and file system full

[Fred Martin_1]

Had a problem today, the /home file system hit 100% - I discovered the following in the 'tom' home directory:

/home/tom/tom.2373
/home/tom/tom.2376

...etc.

These files are owned by tom:mail and are each about 60 megs.

Looked at the file /var/mail/tom, and found it also to be aboout 60 megs.

It appears that he sent out several very large files, Cc:'d to many people, half them bounced back because of file size limits on recieving servers. That of course, sends the whole_dang_file back to him, many times over.

The question is, am I right? Does sendmail hit some limit in /var/mail, then default to /home/ if it can't put the mail in /var/mail?

I don't think /var was full at the time.

[Fred Martin_1]

Ok, the files in /home are being created as fast as I can delete them. How can I stop this without shutting down sendmail?

[Christopher McCray_1 · Accepted solution]

Hello,

Check this doc:

http://support2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000055292990

and som older docs:

http://support2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000014316994

http://support2.itrc.hp.com/service/cki/docDisplay.do?docLocale=en_US&docId=200000033339954

Maybe it will help

Chris

[Christopher McCray_1]

Hello,

Does he have a crontab entry that is doing this possibly?

If so, comment it out.

You may want to shut down sendmail if it is as bad as you say it is; at least to give you breathing room.

What does your /var/adm/syslog/mail.log say?

Chris

[Tom Maloy]

Brute force would be to remove write permission to the directory, or write a cron job that runs every minute (or so) and removes the files in the ~tom directory.

Tom

[Fred Martin_1]

The incoming files finally subsided on their own. There are no errors in the mail.log, and only file system full errors in the syslog.log.

[Sean OB_1]

What do you see in the mail log regarding Tom? Do you see many outbound messages? Returned messages?

I don't think mail writes to the home directory for mail if it can't write to var.

And since you stated that /var wasn't full even it did this wouldn't have been the case.

Perhaps the client Tom is using dumps temp files to his home directory while it's creating the mail?

[Bill Hassell]

If you have a sendmail storm like this, your defense is to shutdown sendmail. No messages will be lost as the SMTP protocol will just retry the connection later. There is nothing in sendmail that can sense a user's problem. Each message stands on it's own merit so sendmail can't figure out why /var/mail is full.

One way to 'empty' the mail storm for a single user is to redirect the user's email to a different directory using /etc/mail/aliases. Make sure you run newaliases after making changes to the aliases file. That will give you some breathing room. The user can browse their messages with elm -f /someother/directory/username and cleanup the junk.

Once the messages quit coming in, you can turn off sendmail, merge the current mailbox with any others that were saved off and put everything back. NOTE: this is one of the strongest reasons to have /var/mail as a separate (and large, multi-gigabyte) directory.