>In the past week, sendmail has stop listening to port 25 several times. I
>tried
>restarting sendmail, it didn't work. The only thing that will work is to
>reboot
>the machine and sendmail listens to port 25. But it won't last long until the
>next day or so and I have to reboot the machine again. ps and lsof command
>says
>sendmail is still running as a daemon and lsof -i/netstat produce no results on
>port 25 or smtp port that is being listen. I telnet to the machine using port
>25, instead of connecting to sendmail, it refused and closed the connection.
I have several responses and I would like to thank for those for responding
quickly.
>Kevin P. Inscoe wrote:
>
>There is a setting (I forget what it is now) in sendmail.cf for uptime.
>Basically
>if the uptime (in our case it was 8) is higher then this number sendmail shuts
>down. It runs but it lays dormant and will not empty mqueue or respond to new
>connects.
>It happened to us once before we lowered the value.
There was no uptime I can find in sendmail.cf
>ari wrote:
>
>Check your disk space. For example, if you have /var/spool/mqueue (and/or
>related directories) and /var/tmp on the same partition, then when the
>temporary directory fills, sendmail will reject all connections. Upon reboot,
>the temporary directory may be cleared, in which case sendmail will accept
>connections again.
That happen before when somebody has submitted a huge print job and caused /var
slice to fill up; therefore, shutting down sendmail queue. I have relocated
/var/spool to a bigger partition. For this incident, there was plenty of spaces
in /var/spool and /tmp
>Chris Marble wrote:
>
>We had similar problems for a while after our router was reconfigured to block
>access to some ports. Maybe you have a network admin that did something
>similar
>or there's some new firewall rules.
No changes in our network
>Paul Pescitelli wrote:>
>
>I would install the latest version of sendmail. There are many hackable
>doors in sendmail, it pays to stay with the latest version..
I upgraded the sendmail to v8.9.3, but the problem still there.
Though sendmail v8.9.3 did send more meaningful error messages in syslog then
v8.8.8
Sorry if I missed others, sendmail disconnected again that time.
Solution:
message extracted from syslog
Nov 14 04:27:38 sunfs sendmail[8554]: runqueue: Skipping queue run -- load avera
ge too high
Both sendmail 8.8.8 and 8.9.3 did have load average function compiled in and
during that time, the load average has exceeded the default settings causing
sendmail to disconnect the smtp port (25). Rebooting sendmail will not work
because the high load average still exist. Rebooting the system did the trick
but not a solution since the load average will go up again.
According to O'Reilly Sendmail book, whenever the load average become to high,
it disconnects the smtp port until the load average becomes low.
to find out what the current load average, type this command at the prompt
# sendmail -d3.30 yourusername < /dev/null
shouldqueue: CurrentLA=17, pri=30000: FALSE (CurrentLA > QueueLA)
the load average was to high
More info from the book
If the load average exceeds QueueLA (default 8), it stops delivering the mail,
if load average exceeds RefuseLA (default 12) it stops accepting the mail. Both
of the settings are located in sendmail.cf
Setting the value high will probably prevent sendmail from disconnecting but
will not solve the load average.
So I set out to find out what causing the system to have such a high load
average.
I ran proctool and found out httpd (sun webserver v2) was utilizing 97% of the
cpu. (I have overlooked this and didn't expect httpd was contributing the
problem to sendmail)
I kill the httpd and the load average went down to zero.
The take care of that problem to sendmail :)
My next job is to find out why the httpd was utilizing large percentoage of cpu.
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
Shawn Kondel Computer Specialist
Department of Mathematics & Statistics Email: shawnk@math.usu.edu
Utah State University Phone: (435) 797-4061
3900 Old Main Hill Fax: (435) 797-1822
Logan, UT 84322-3900 Web: www.math.usu.edu
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
"UNIX was not designed to stop you from doing stupid things, because that
would also stop you from doing clever things." -- Doug Gwyn
This archive was generated by hypermail 2.1.2 : Fri Sep 28 2001 - 23:13:33 CDT