On Tue, 23 Aug 2005, Rainer Zocholl wrote:
Hello
Hi
i don't know if this list is right.
If not pls. drop my a mail.
This is probably your best route
Situation:
No mail leaving box after an aptitude upgrade
# netstat -tulpen
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
User Inode PID/Program name
tcp 0 0 0.0.0.0:25 0.0.0.0:* LISTEN
0 5385889 6919/inetd
Ouch... why is inetd listening on port 25 ? That will really slow things
down, you'd be much better off with sendmail running in daemon mode !
# /etc/init.d/sendmail start
Starting Mail Transport Agent: sendmailsendmail mta daemon not needed, not
started.
That's (partly) ok, because it happens that this box runs a tool optuse smtpd
which happens to be installed in /usr/sbin/smtpd. ("local" or "opt" might
have been more adwisable, but...)
hrm, bad choice of names (smtpd) ...
The problem:
The sendmail IS configured and expected to do local delivery and
has to listen on port 127.0.0:587 (submission).
That was configured with:
boxk:~# grep 127.0.0 /etc/mail/sendmail.mc
dnl DAEMON_OPTIONS(`Name=MSA,Port=submission,Addr=127.0.0.1,M=E')dnl
The leading 'dnl' means that line is a comment - sendmail is not running
(per above start command), and if it was, it wouldn't be listening on 587
As long as sendmail was started manually all went well.
Now, after an update, the /etc/init.d/sendmail was changed so
nothing listens at submission anymore...
What did you upgrade from ? Have you peeked at /etc/mail/sendmail.conf ?
So it happens tht the mail quue became so large, that just
to read in the directory takes 30 minutes!
30 minutes to read the directory? How large is that queue ?
But sendmail-que was started even 20 min!
#grep send /etc/cron.d/sendmail
# Every so often, give sendmail a chance to run the MSP queues.
*/20 * * * * smmsp test -x /usr/share/sendmail/sendmail
&& /usr/share/sendmail/sendmail cron-msp
cron-msp gives locally generated mail to the mta for eventual delivery,
moving files from /var/spool/mqueue-client to /var/spool/mqueue
# Every so often, give sendmail a chance to run the MTA queues.
*/10 * * * * root test -x /usr/share/sendmail/sendmail
&& /usr/share/sendmail/sendmail cron-mta
This one attempts to deliver files externally and locally
That leads to a high load because finally 10 or more sendmail-que
were running, stealing each others CPU cycles and causing to swap.
Increasing the time intervall or using a bigger box is no solution,
because there are only "spam hours" which generates such a lot
of mails and the box is "normally" absoletely sufficient.
What kind of setup are you looking for ? Right now it appears that you
have:
*) inetd invoking sendmail (very non-optimal) for each request
to port 25
*) msp->mta queue runs every 20 minutes
*) mta delivery queue runs every 10 minutes
Problems:
a) Why is there no "already running" block in sendmail msp?
Good point, adding cron/inetd support for sendmail was done relatively
recently - and not tested in heavy loads... With sendmail in daemon
mode, the queue is almost always empty, so this probably was just
missed.
b) Why is the setup not aware of a local delivery submission only sendmail?
(That might be a problem of our setup, but how to work arround?)
Either I'm miss-parsing your question, or it sounds like you've upgraded
from something before 8.11.0 - when sendmail was split into two pieces
for enhanced security:
*) sgid Message Submission Program (MSP) that is used for local
mail injection (ala mailx, /usr/sbin/sendmail...)
*) suid Message Transport Agent (MTA) that runs without root
whenever possible, but must start as root for port 25/587 binding
This process handles receipt of foreign mail, and delivery - both
local and external.
/etc/mail/sendmail.conf allows for tuning the way these processes run:
*) Combined listener (25/465/587) and delivery daemon
*) Separate listener (25/465/587) and delivery daemons
*) running the above (separately) via daemon, inetd, or cron
If I'm missing a mode you need, please let me know and we'll work out
something we can both live with :)
c) Why is the existence of a file sufficient to decide if a special
package is installed or not?
I had to use something to detect the presence of the smtpd package, and
since /usr/share/doc is optional - I couldn't think of any better test !
I could add a variable in /etc/mail/sendmail.conf to mark the usage of
smtpd - it would default to OFF unless /usr/sbin/smtpd was found - then
it would default to ON, but your changes would survive upgrades so you'd
not have to tweak it again :)
In fact, I think that is a good idea !
Anyway, please let me know if any of this helps - and do prompt for
more information if you need it !
--
Rick Nelson
<Culus> dhd: R you part of the secret debian overstructure?
<dhd> no. there is no secret debian overstructure.
<CosmicRay> although, now that somebody brought it up, let's start one
:-)
<Knghtbrd> CosmicRay - why not, sounds like a fun way to spend the
afternoon =D
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
