Where should we start on preventing this type of problem?
[root@server34 mqueue]# find | wc -l 185259
-jason
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited.
On Thu, Feb 21, 2008 at 9:05 AM, Jason Pyeron jpyeron@pdinc.us wrote:
Where should we start on preventing this type of problem?
[root@server34 mqueue]# find | wc -l 185259
Short answer: We can't.
Long answer: Need to know a lot more about the problem before one can even try to fix a problem like this:
1) What are the emails from? Single program? Single user? Multiple issues etc 2) Where are the emails coming from? 3) Who are the emails are going to? 4) What kind of network setting is it. 5) What kind of server is this? [Mail server, mail gateway, personal desktop, etc]
These are just starting questions..
Jason Pyeron wrote:
Where should we start on preventing this type of problem?
[root@server34 mqueue]# find | wc -l 185259
/etc/init.d/sendmail stop chkconfig --level 2345 sendmail off find /var/spool/mqueue -type f -exec rm -f {} ;
That'll empty out your queue and you won't have to worry about it building up again, pesky thing!
:)
nate
/etc/init.d/sendmail stop chkconfig --level 2345 sendmail off find /var/spool/mqueue -type f -exec rm -f {} ;
That'll empty out your queue and you won't have to worry about it building up again, pesky thing!
Hmm...it will still build. To really fix it, you need to do one more step:
rpm -e --nodeps sendmail
Now that is a permanent solution.
On Monday 25 February 2008, Christopher Chan wrote:
Hmm...it will still build. To really fix it, you need to do one more step:
rpm -e --nodeps sendmail
Now that is a permanent solution.
Like a hand grenade is a "solution". Not likely to help him much, tho. =/ Doesn't even begin to address his situation since sendmail wasn't the problem to begin with.
Seems to me that it's a bad idea to use NFS as a mail store. For example, the RedHat documentation specifically recommends strongly *against* it. Very flatly:
Never put the mail spool directory, /var/spool/mail/, on an NFS shared volume.
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/s1-serv...
Also, NFS has various locking problems which prevent its use in a proper mail cluster. Read up on sendmail's mbox vs qmail's maildir for more details. Not suggesting that you switch to qmail, with it's "recompile the whole !@#! thing every time you change a config option" mentality, but it's useful information nonetheless, especially when you get into having multiple mail receipt hosts.
The additional complexity of NFS is what seems to have caused this gentleman's problem - not only did sendmail itself have to work properly, so did NFS, DNS, and the spam filter.
How to avoid it? Either:
1) Reduce complexity. (get rid of the need for DNS, NFS, etc. or
2) "Beef up" the various pieces so they don't fail - make sure you are using high quality servers and equipment, or
3) Increase redundancy, so that no single point of failure exists.
Why is he depending on a single DNS server? Why is he using NFS, with it's implicit single-point-of-failure rather than GlusterFS, which provides multiple-primary-host redundancy and automatic failover? http://www.gluster.org/
-Ben
Benjamin Smith wrote:
On Monday 25 February 2008, Christopher Chan wrote:
Hmm...it will still build. To really fix it, you need to do one more step:
rpm -e --nodeps sendmail
Now that is a permanent solution.
Like a hand grenade is a "solution". Not likely to help him much, tho. =/ Doesn't even begin to address his situation since sendmail wasn't the problem to begin with.
Whooosh! Did you see that flying over your head?
Seems to me that it's a bad idea to use NFS as a mail store. For example, the RedHat documentation specifically recommends strongly *against* it. Very flatly:
/me shrugs. Pick your poison. Besides, Redhat is not the absolute authority on how to run a mail system.
Never put the mail spool directory, /var/spool/mail/, on an NFS shared volume.
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security-guide/s1-serv...
Also, NFS has various locking problems which prevent its use in a proper mail cluster. Read up on sendmail's mbox vs qmail's maildir for more details. Not suggesting that you switch to qmail, with it's "recompile the whole !@#! thing every time you change a config option" mentality, but it's useful information nonetheless, especially when you get into having multiple mail receipt hosts.
procmail, postfix local, maildrop all support maildir. qmail is not even necessary. Or is this your excuse to do a bit of qmail bashing?
The additional complexity of NFS is what seems to have caused this gentleman's problem - not only did sendmail itself have to work properly, so did NFS, DNS, and the spam filter.
Yawn. postfix + mysql + courier-authlib + cyrus-sasl + vpopmail + spamassassin + clamav + maildrop.
How to avoid it? Either:
- Reduce complexity. (get rid of the need for DNS, NFS, etc. or
What is your proposal for getting rid of DNS? I, for one, would like to see how you intend to make email work without dns.
- "Beef up" the various pieces so they don't fail - make sure you are using
high quality servers and equipment, or
- Increase redundancy, so that no single point of failure exists.
Why is he depending on a single DNS server? Why is he using NFS, with it's implicit single-point-of-failure rather than GlusterFS, which provides multiple-primary-host redundancy and automatic failover? http://www.gluster.org/
I do not know the answer to that one hotshot. Maybe you can ask the OP nicely?
Christopher
On Wednesday 27 February 2008, Christopher Chan wrote:
procmail, postfix local, maildrop all support maildir. qmail is not even necessary. Or is this your excuse to do a bit of qmail bashing?
Qmail bashing? Not at all. But I'm not endorsing Qmail, either, and I'm nice enough to say why... =) But there is a good analysis there of the advantages of maildir over mbox, especially when you start clustering and/or using shared storage resources.
The additional complexity of NFS is what seems to have caused this
gentleman's
problem - not only did sendmail itself have to work properly, so did NFS, DNS, and the spam filter.
Yawn. postfix + mysql + courier-authlib + cyrus-sasl + vpopmail + spamassassin + clamav + maildrop.
You're so cool! (But OP got bit)
How to avoid it? Either:
- Reduce complexity. (get rid of the need for DNS, NFS, etc. or
What is your proposal for getting rid of DNS? I, for one, would like to see how you intend to make email work without dns.
Read OP.
He had a DNS failure which affected NFS is what screwed up mail delivery. Obviously, the mail server was doing something, even though DNS was at least partially unavailable. DNS isn't strictly necessary for NFS mounts, (which is the root of OP's problem) so configuring his servers so that a similar DNS failure happening wouldn't h0rk his NFS mount might be a good idea.
Maybe.
- "Beef up" the various pieces so they don't fail - make sure you are
using
high quality servers and equipment, or
- Increase redundancy, so that no single point of failure exists.
Why is he depending on a single DNS server? Why is he using NFS, with it's implicit single-point-of-failure rather than GlusterFS, which provides multiple-primary-host redundancy and automatic failover? http://www.gluster.org/
I do not know the answer to that one hotshot. Maybe you can ask the OP nicely?
Hotshot? Just asking questions about his config that hopefully steer him towards a more reliable configuration.
(hotshot?)
(hotshot?)
Well, you came across as a 'I know everything and you must do as I say' in your response to a subthread that had turned into a joke.
I mean, come on! We were discussing how to completely thrash his mail system.
Even the OP got into it. Sheesh. Maybe I should have called the OP hotshot instead. After all, he issued the 'rm -fr / && reboot'. Are you with us yet?
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of Benjamin Smith Sent: Tuesday, February 26, 2008 10:34 To: CentOS mailing list Subject: Re: [CentOS] Huge mailq
On Monday 25 February 2008, Christopher Chan wrote:
Hmm...it will still build. To really fix it, you need to do
one more step:
rpm -e --nodeps sendmail
Now that is a permanent solution.
Like a hand grenade is a "solution". Not likely to help him much, tho. =/ Doesn't even begin to address his situation since sendmail wasn't the problem to begin with.
Seems to me that it's a bad idea to use NFS as a mail store. For example, the RedHat documentation specifically recommends strongly *against* it. Very flatly:
Never put the mail spool directory, /var/spool/mail/, on an
NFS shared
volume.
http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/security
-guide/s1-server-mail.html
Good to know. This will be new top priority fix.
Also, NFS has various locking problems which prevent its use in a proper mail cluster. Read up on sendmail's mbox vs qmail's maildir for more details. Not suggesting that you switch to qmail, with it's "recompile the whole !@#! thing every time you change a config option" mentality, but it's useful information nonetheless, especially when you get into having multiple mail receipt hosts.
The additional complexity of NFS is what seems to have caused this gentleman's problem - not only did sendmail itself have to work properly, so did NFS, DNS, and the spam filter.
How to avoid it? Either:
Reduce complexity. (get rid of the need for DNS, NFS, etc. or
"Beef up" the various pieces so they don't fail - make
sure you are using high quality servers and equipment, or
- Increase redundancy, so that no single point of failure exists.
Why is he depending on a single DNS server? Why is he using NFS, with it's implicit single-point-of-failure rather than GlusterFS, which provides multiple-primary-host redundancy and automatic failover? http://www.gluster.org/
These are the types of steps we are taking now.
-Ben
-- Only those who reach toward a goal are likely to achieve it.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited.
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of nate Sent: Monday, February 25, 2008 21:47 To: centos@centos.org Subject: Re: [CentOS] Huge mailq
Jason Pyeron wrote:
Where should we start on preventing this type of problem?
[root@server34 mqueue]# find | wc -l 185259
/etc/init.d/sendmail stop chkconfig --level 2345 sendmail off find /var/spool/mqueue -type f -exec rm -f {} ;
Funny,
But we tried an even esier rm -rf / && reboot
That'll empty out your queue and you won't have to worry about it building up again, pesky thing!
:)
nate
CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100 - - +1 (443) 269-1555 x333 Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, purge the message from your system and notify the sender immediately. Any other use of the email by you is prohibited.
Jason Pyeron wrote:
-----Original Message----- From: centos-bounces@centos.org [mailto:centos-bounces@centos.org] On Behalf Of nate Sent: Monday, February 25, 2008 21:47 To: centos@centos.org Subject: Re: [CentOS] Huge mailq
Jason Pyeron wrote:
Where should we start on preventing this type of problem?
[root@server34 mqueue]# find | wc -l 185259
/etc/init.d/sendmail stop chkconfig --level 2345 sendmail off find /var/spool/mqueue -type f -exec rm -f {} ;
Funny,
But we tried an even esier rm -rf / && reboot
Eheh, but the '&& reboot' part is rather useless as the reboot symlink should have disappeared once the 'rm -rf /' has done its magic ;).
-
Benjamin Smith -
Christopher Chan -
Jason Pyeron -
nate -
Stephen John Smoogen -
Ugo Bellavance