Message queue table nearly full. How do I fix this

[Joe Profaizer]

I think this may be a result of the messages going to a non-existent email address. The employee's last day was April 1st. The exchange administrator removed his account, but on the unix side, there are still many programs that are trying to send emails to this non-existent account.

Is there a way to flush the message queue or redirect it to an existing email account?

thanks

[Pete Randall]

Joe,

How about setting up an alias? See "man aliases".


Pete

[Robert-Jan Goossens]

Hi Joe,

How about creating an alias for this user.

check the /etc/aliases file.

run newaliases after a change.

Best regards,
Robert-Jan

[Joe Profaizer]

OK. Since his username was joeblow, I made an entry in /etc/aliases as:
joeblow : root

Saved the file and ran:
newaliases

Should this do the trick?

I still see the message queue alert at 97%(glance -t)
Message Table (msgmni) 300 290 97 97

Let me know if I need to do something different.

Thanks folks!

[Robert-Jan Goossens]

How vital are the messages ? You could dump your sendmail queue with "sendmail -q -v" or bounce the sendmail daemon.
Robert-Jan

[Pete Randall]

I was wondering if we weren't talking about two different things. Quoting SAM's Help on Configurable Parameters, "Messages are small collections of data (400 bytes, for example) that can be passed between cooperating programs through a message queue". To increase msgmni, you'll need to create a new kernel. Use SAM to increase the msgmni paramter, then generate a new kernel.


Pete

[Joe Profaizer]

Thanks, but that still didn't free up msgmni. I suppose I'll have to create a new kernel and reboot.

[Bill Hassell · Accepted solution]

msgmni has nothing to do with email. This is an in-core messaging system and the message count is increasing because programs are creating more messages. If your applications are growing, this may be perfectly normal (nothing to do with the previous employee) and you just need to double or triple the value for msgmni. Use ipcs -qa to look at the current values.

The email situation you describe *only* affects the directory: /var/mail, and specifically the joeblow file. There are several ways to address this:

- Remove the user joeblow from the system and also remove the /var/mail/joeblow file.

- alias joeblow to root (bad idea, now root gets all the junk email, but at least you know where it's coming from)

- alias joeblow to /dev/null as in: joeblow : /dev/null

[Geoff Wild]

Sure - every now and then, stop sendmail, rm -f /var/spool/mqueue/* , then start sendmail

Real solution - fix the scripts not to email to a non-existent id.

Rgds..Geoff

[Fred Martin_1]

We don't remove accounts in unix immediately, instead I disable the account and then delete accounts once every six months or so.

This creates a problem like you are having: a avalid email account where there is no one around to read the email.

I do this in the aliases file:

joeblow : nomail

Even though there is still a valid inbox for joeblow, this attempts to deliver the mail to nomail instead.

There is no 'nomail' account. So, the mail bounces back to the sender with this error:

-- The following addresses
had permanent fatal errors --
nomail
(reason: 550 5.1.1 User unknown)
(expanded from: )

This teaches the senders to stop sending email to this guy, especially if they have him in buddy lists, etc. and don't realize it.

Scripts though, you'll need to manage that.