He already knows that sendmail accepts connections. Maillog is of no help
(maybe with a higher log level, I know that you can get even more info with
14). He has to identify the cause of the timeout and the first step is to
identify the phase where it happens.
Kai
Hi folks,
Name resoluti
Les Mikesell wrote on Tue, 10 Jun 2008 07:49:09 -0500:
> A 'make' is run when the sendmail init script starts that will rebuild
> sendmail.cf from sendmail.mc if it is newer, and all the databases if
> their corresponding text file is newer.
I was aware about the latter, not the former. You are
Kai Schaetzl wrote:
I made that change
you suggested in the webmin interface (sendmail.m4) and rebuilt it from
there.
You can m4 rebuild the sendmail.cf from the sendmail section in webmin? I
wouldn't be to sure about that. I haven't ever noticed that might be
possible (I use webmin only t
Ray Leventhal wrote on Mon, 09 Jun 2008 17:02:43 -0400:
> I made that change
> you suggested in the webmin interface (sendmail.m4) and rebuilt it from
> there.
You can m4 rebuild the sendmail.cf from the sendmail section in webmin? I
wouldn't be to sure about that. I haven't ever noticed that
On Mon, Jun 09, 2008 at 04:46:47PM -0400, Ray Leventhal wrote:
> >DNS. It's always DNS :-)
> While I agree, I'm still a bit stumped. Nothing changed other than a
> reboot on Sunday afternoon. I do have Friday's rsync snapshot and running
> diff against the sendmail files (cf/mc) as well as hos
DNS. It's always DNS :-)
(more accurately, host and IP address resolution).
How long is it taking your server to resolve the IP address into a
name? To resolve names into IP addresses? To resolve destination MX
records?
Hi Stephen,
While I agree, I'm still a bit stumped. Nothing cha
Kai Schaetzl wrote:
Ray Leventhal wrote on Mon, 09 Jun 2008 11:42:27 -0400:
Do you think it's wise to replace the sendmail.cf and sendmail.mc files
from the snapshot (after backing them up, of course)?
If you did not change the files: no. As I said: go thru a manual send and
check *w
On Mon, Jun 09, 2008 at 11:34:11AM -0400, Ray Leventhal wrote:
> This now seems like a timeout issue. Increasing client-side timeout to
> > 180 seconds gets mail going just fine.
>
> Any ideas on what might be happening since a reboot to cause this change
> in MTA behaviour would be greatly app
Ray Leventhal wrote on Mon, 09 Jun 2008 11:42:27 -0400:
> Do you think it's wise to replace the sendmail.cf and sendmail.mc files
> from the snapshot (after backing them up, of course)?
If you did not change the files: no. As I said: go thru a manual send and
check *where* the timeout occurs (b
where does the server point to for its dns? if it's (supposed to be)
running a nameserver (e.g., you're pointing to 127.0.0.1) but the dns
server isn't running you'll get a timeout. if you have a second
nameserver configured in /etc/resolv.conf you'll likely ultimately
get a response, but only
lists-centos wrote:
are you configured for spamassassin or clamav as milters on the
server (in the sendmail.cf) and either/both of these didn't start up
on the reboot? sendmail will still accept mail with sa/clamav not
running, but it takes a bit longer.
there's also the possibility of an invers
Kai Schaetzl wrote:
so, it's a connection to itself. was this a test to localhost?
If not, that hints in the direction of the problem.
Maybe you accidentally set the smarthost to itself or so?
I'd try a manual connect and walk thru an SMTP conversation and send a mail.
Also, clients can produce d
This now seems like a timeout issue. Increasing client-side timeout to
> 180 seconds gets mail going just fine.
Any ideas on what might be happening since a reboot to cause this change
in MTA behaviour would be greatly appreciated.
Regards,
-Ray
__
Ray Leventhal wrote on Mon, 09 Jun 2008 09:48:22 -0400:
> increase in the log level produced lines like this in /var/log/maillog:
> Jun 9 09:28:51 gungho sendmail[13243]: m59DRxV2013243: gungho
> [172.16.0.106] did not issue MAIL/EXPN/VRFY/ETRN during connection to smtp
>
> 172.16.0.106 is the
no change in connection to the mail server. clients connect, but time out.
increase in the log level produced lines like this in /var/log/maillog:
Jun 9 09:28:51 gungho sendmail[13243]: m59DRxV2013243: gungho
[172.16.0.106] did not issue MAIL/EXPN/VRFY/ETRN during connection to smtp
172.16.0
lingu wrote:
Hi lingu,
Thanks for your reply.
Check the below things on your server.
1) diskspace
df -h shows 253GB free on the LVM which holds mail
2) mailq
mailq says 'mailqueue is empty'
3) netstat -ntlp |grep :25 |grep tcp
# netstat -ntlp|grep :25|grep tcp
tcp0 0 0.0.0.
Ray Leventhal wrote:
HI folks,
I've an up-to-date CentOS 5.x box on a small intranet (<20 users).
We did a reboot over the weekend and all appears well except that
clients on the LAN can no longer send email. Just hangs/times out.
No clear identifiers in the /var/log/maillog or /var/log/mes
HI,
Check the below things on your server.
1) diskspace
2) mailq
3) netstat -ntlp |grep :25 |grep tcp
4) telnet on port 25 from server as well as from client
5) ps auxxww |grep sendmail
you should get output like below###
root 794 0.0 0.0
Ray Leventhal wrote:
HI folks,
I've an up-to-date CentOS 5.x box on a small intranet (<20 users).
We did a reboot over the weekend and all appears well except that
clients on the LAN can no longer send email. Just hangs/times out.
No clear identifiers in the /var/log/maillog or /var/log/mes
HI folks,
I've an up-to-date CentOS 5.x box on a small intranet (<20 users).
We did a reboot over the weekend and all appears well except that
clients on the LAN can no longer send email. Just hangs/times out. No
clear identifiers in the /var/log/maillog or /var/log/messages.
We're not set
20 matches
Mail list logo
