Re: connections hanging around forever
> From: Charlie Brady <[EMAIL PROTECTED]> > Date: Fri, 31 Aug 2007 13:49:02 -0400 (EDT) > > > On Fri, 31 Aug 2007, Chris Garrigues wrote: > > >> From: Chris Garrigues <[EMAIL PROTECTED]> > >> Date: Wed, 29 Aug 2007 09:27:42 -0500 > ... > >> Any idea what's going on here? It requires a -9 to kill the processes. > ... > > and then it hangs forever and requires a -9. > > Are you quite sure of that? What happens if you use a TERM or QUIT signal? > Have you attached strace (or whatever syscall tracing tool is appropriate > for your platform)? I just confirmed it. If I strace I just see that it's hanging on "read(0, ". Since I hadn't diagnosed what was triggering it until just now, I didn't know how to provide a test case. Now that I do, I'll try to get a real strace. > > Am I doing the wrong thing, is this a bug, or is there something odd about > > my > > system? > > Last time I looked the qpsmtpd timeout alarm only applied while parsing > SMTP or while receiving messages, but not while plugins were executing. I > haven't seen any discussion about possible fixes for that (but I haven't > checked that it hasn't been fixed). That could explain qpsmtpd waiting > forever, but wouldn't explain faulure to terminate on TERM and QUIT > signals. Note that it's no longer in my plugin at this point. Chris -- Chris Garrigues Trinsic Solutions President 710-B West 14th Street Austin, TX 78701-1798 http://www.trinsics.com/blog http://www.trinsics.com 512-322-0180 Would you rather proactively pay for uptime or reactively pay for downtime? Trinsic Solutions Your Trusted Friends in Proactive IT. pgp0dIPS1tDDy.pgp Description: PGP signature
Re: connections hanging around forever
> From: Chris Garrigues <[EMAIL PROTECTED]> > Date: Fri, 31 Aug 2007 13:09:52 -0500 > > > From: Charlie Brady <[EMAIL PROTECTED]> > > Date: Fri, 31 Aug 2007 13:49:02 -0400 (EDT) > > > > > > On Fri, 31 Aug 2007, Chris Garrigues wrote: > > > > >> From: Chris Garrigues <[EMAIL PROTECTED]> > > >> Date: Wed, 29 Aug 2007 09:27:42 -0500 > > ... > > >> Any idea what's going on here? It requires a -9 to kill the processes. > > ... > > > and then it hangs forever and requires a -9. > > > > Are you quite sure of that? What happens if you use a TERM or QUIT signal? > > Have you attached strace (or whatever syscall tracing tool is appropriate > > for your platform)? > > I just confirmed it. If I strace I just see that it's hanging on "read(0, ". > > Since I hadn't diagnosed what was triggering it until just now, I didn't know > how to provide a test case. Now that I do, I'll try to get a real strace. > > > > Am I doing the wrong thing, is this a bug, or is there something odd > > > about my > > > system? > > > > Last time I looked the qpsmtpd timeout alarm only applied while parsing > > SMTP or while receiving messages, but not while plugins were executing. I > > haven't seen any discussion about possible fixes for that (but I haven't > > checked that it hasn't been fixed). That could explain qpsmtpd waiting > > forever, but wouldn't explain faulure to terminate on TERM and QUIT > > signals. > > Note that it's no longer in my plugin at this point. Okay, I did an strace while telnetting to the smtp port. If I type "quit" after I get the 550, it does the right thing, but if I just let it sit there, it never times out. According to the strace: write(2, "21349 Plugin tarpit, hook deny r"..., 51) = 51 write(2, "21349 550 No such user as utterl"..., 60) = 60 write(1, "550 No such user as utterlybogus"..., 55) = 55 alarm(120) = 0 read(0, 0x8c43798, 4096)= ? ERESTARTSYS (To be restarted) --- SIGALRM (Alarm clock) @ 0 (0) --- sigreturn() = ? (mask now []) rt_sigprocmask(SIG_BLOCK, [ALRM], NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [ALRM], NULL, 8) = 0 read(0, The read following the alarm does indeed wait for 120 seconds, but then the alarm is blocked ...and I've just concluded that the problem must be in a library of my own called by my code. It's code that I wrote years ago...I'll have to figure out why I blocked the signals that I did when I did. Thanks for helping me find the problem in my own code. Chris -- Chris Garrigues Trinsic Solutions President 710-B West 14th Street Austin, TX 78701-1798 http://www.trinsics.com/blog http://www.trinsics.com 512-322-0180 Would you rather proactively pay for uptime or reactively pay for downtime? Trinsic Solutions Your Trusted Friends in Proactive IT. pgpZsDDAX5nTU.pgp Description: PGP signature
Re: connections hanging around forever
On Fri, 31 Aug 2007, Chris Garrigues wrote: From: Chris Garrigues <[EMAIL PROTECTED]> Date: Wed, 29 Aug 2007 09:27:42 -0500 ... Any idea what's going on here? It requires a -9 to kill the processes. ... and then it hangs forever and requires a -9. Are you quite sure of that? What happens if you use a TERM or QUIT signal? Have you attached strace (or whatever syscall tracing tool is appropriate for your platform)? Am I doing the wrong thing, is this a bug, or is there something odd about my system? Last time I looked the qpsmtpd timeout alarm only applied while parsing SMTP or while receiving messages, but not while plugins were executing. I haven't seen any discussion about possible fixes for that (but I haven't checked that it hasn't been fixed). That could explain qpsmtpd waiting forever, but wouldn't explain faulure to terminate on TERM and QUIT signals. --- Charlie
Re: connections hanging around forever
> From: Chris Garrigues <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 09:27:42 -0500
>
> Hi all,
>
> I've been using qpsmtpd for about 6 months now but I've just signed up for
> this list. I recently upgraded to 0.40 and I'm running on a modified
> Mandriva
> using qmail and with qpsmtpd running under tcpserver.
>
> I've long had a problem with connections from certain spammers hanging around
> forever. I wrote a script that I run out of cron that sends a -9 to any
> connection that's been around for over an hour and that's kept me up and
> running, but...
>
> Any idea what's going on here? It requires a -9 to kill the processes.
I cranked up logging to see if I could get a clue what it's doing.
I have a hook_rcpt handler that ends with:
$self->log(LOGNOTICE, "$email doesn't exist");
return Qpsmtpd::DSN->no_such_user("No such user as $email");
and what I find in the logs looks like this:
2007-08-31 10:23:17.849806500 18633 trinsixldap plugin: [EMAIL PROTECTED]
doesn't
exist
2007-08-31 10:23:17.849807500 18633 Plugin trinsixldap, hook rcpt returned DENY,
No such user as [EMAIL PROTECTED] (#5.1.1)
2007-08-31 10:23:17.849809500 18633 running plugin (deny): tarpit
2007-08-31 10:23:17.849810500 18633 trying to get config for tarpit_whitelist
2007-08-31 10:23:17.849865500 18633 Plugin tarpit, hook deny returned DECLINED,
2007-08-31 10:23:17.849867500 18633 550 No such user as [EMAIL PROTECTED]
(#5.1.1)
and then it hangs forever and requires a -9.
Am I doing the wrong thing, is this a bug, or is there something odd about my
system?
Chris
--
Chris Garrigues Trinsic Solutions
President 710-B West 14th Street
Austin, TX 78701-1798
http://www.trinsics.com/blog
http://www.trinsics.com 512-322-0180
Would you rather proactively pay for
uptime or reactively pay for downtime?
Trinsic Solutions
Your Trusted Friends in Proactive IT.
pgpMLUxnl5Erp.pgp
Description: PGP signature
Re: connections hanging around forever
> From: "Sydney Bogaert" <[EMAIL PROTECTED]>
> Date: Wed, 29 Aug 2007 17:40:33 +0200
>
> Did you try to set the timeout in the configuration files ?
> echo -n 600 > config/timeout
> By default it is set to 1200 seconds (20 minutes).
I've got 120 in /var/qmail/control/timeoutsmtpd; based on the below code, that
should work.
> See in lib/Qpsmtpd/TcpServer.pm :
>
> sub read_input {
> my $self = shift;
>
> my $timeout =
> $self->config('timeoutsmtpd') # qmail smtpd control file
> || $self->config('timeout') # qpsmtpd control file
> || 1200;# default value
>
> alarm $timeout;
> while () {
> alarm 0;
> $_ =~ s/\r?\n$//s; # advanced chomp
> $self->log(LOGINFO, "dispatching $_");
> $self->connection->notes('original_string', $_);
> defined $self->dispatch(split / +/, $_, 2)
> or $self->respond(502, "command unrecognized: '$_'");
> alarm $timeout;
> }
> alarm(0);
> }
>
> If you have connections running for more than one hour, the client must
> be saying something during this time.
> You can try to lower the timeout parameter. Mine is 120s (maybe a
> little short, but it works quite well).
>
>
> Sydney.
--
Chris Garrigues Trinsic Solutions
President 710-B West 14th Street
Austin, TX 78701-1798
http://www.trinsics.com/blog
http://www.trinsics.com 512-322-0180
Would you rather proactively pay for
uptime or reactively pay for downtime?
Trinsic Solutions
Your Trusted Friends in Proactive IT.
pgpdVfOKIDksj.pgp
Description: PGP signature
RE: connections hanging around forever
>
> Hi all,
>
> I've been using qpsmtpd for about 6 months now but I've just
> signed up for
> this list. I recently upgraded to 0.40 and I'm running on a
> modified Mandriva
> using qmail and with qpsmtpd running under tcpserver.
>
> I've long had a problem with connections from certain
> spammers hanging around
> forever. I wrote a script that I run out of cron that sends
> a -9 to any
> connection that's been around for over an hour and that's
> kept me up and
> running, but...
>
> Any idea what's going on here? It requires a -9 to kill the
> processes.
>
> Should I not be running under tcpserver? Also, why does the
> default run
> script default to -c 10; that seems awfully low to me.
>
> Chris
>
Did you try to set the timeout in the configuration files ?
echo -n 600 > config/timeout
By default it is set to 1200 seconds (20 minutes).
See in lib/Qpsmtpd/TcpServer.pm :
sub read_input {
my $self = shift;
my $timeout =
$self->config('timeoutsmtpd') # qmail smtpd control file
|| $self->config('timeout') # qpsmtpd control file
|| 1200;# default value
alarm $timeout;
while () {
alarm 0;
$_ =~ s/\r?\n$//s; # advanced chomp
$self->log(LOGINFO, "dispatching $_");
$self->connection->notes('original_string', $_);
defined $self->dispatch(split / +/, $_, 2)
or $self->respond(502, "command unrecognized: '$_'");
alarm $timeout;
}
alarm(0);
}
If you have connections running for more than one hour, the client must
be saying something during this time.
You can try to lower the timeout parameter. Mine is 120s (maybe a
little short, but it works quite well).
Sydney.
