MailScanner stopping

[Glenn Steen]

On 13/09/06, Kevin Miller <Kevin_Miller at ci.juneau.ak.us> wrote:
> Glenn Steen wrote:
> > On 13/09/06, Kevin Miller <Kevin_Miller at ci.juneau.ak.us> wrote:
> >> Last week there was a thread about MailScanner ceasing to work.  I
> >> was seeing that behavior - it was running, but was all balled up.
> >> Turned out that when 'MailScanner restart' was called that some
> >> sendmail processes persisted past the $RESTART_DELAY time.  This
> >> only appears to happen on later MS servers.  Not sure what changes
> >> to the init script make the difference - my 4.48 server doesn't have
> >> a problem.
> >>
> >> The pids that MailScanner creates all evaporate almost immediately;
> >> the persistent sendmail processes are generally (as nearly as I can
> >> tell) connections that smf-sav initiates.  (smf-sav is sorta like
> >> milter-sender and milter-ahead rolled into one.)  I wasn't seeing the
> >> problem until I installed it, but it's too nifty to get rid of even
> >> if it's not as robust as the milters from Snertsoft.
> >>
> >> It can take up to a minute or two for all the connections to expire.
> >> I'm guessing the remote hosts are maybe doing greet-pause or
> >> graylisting when I do the sender verification, which causes them to
> >> sit around for a bit.
> >>
> > Sounds a bit odd... You're not getting tar-pitted by your own internal
> > servers, are you?
>
> Nope - doing a ps aux shows the connections and associated far end.
> Most connections close pretty fast, there's just one or two, maybe three
> that persist.  Not the same one's of course, since at any given random
> moment I could be connected to almost anyone.

Fair enough.

> The idea that some sendmail processes persist longer than the
> $RESTART_DELAY has been mentioned in other contexts for a long time.
> It's just that it was a very random occurance historically.  Now (at
> least in my case) it is more frequent.

And I'm sure you've scrutinized every possible angle (and some
impossible:-) as to why it's more frequent now, so I'll shut up about
that:-)

> I assume that in general it's not a good idea to restart until all is
> cleaned up, hence the hack.
Good idea, yes.
>  A real bash programmer could probably make
> it prettier.
Pretty doesn't come into it when scripting... Usual code health, yes,
but not "pretty":-). After all, when scripting in <insert favourite
shell> we're after function... If we wanted pretty we'd not do it in a
shell:-):-)
>  For some reason the newline doesn't kick in when I echo
> the the output of ps.  Don't know why.  Don't really need the echos in
> there at all, but I find them handy to see where I'm stalled, even if
> the formatting is butt-ugly.

I think I know why, or at least some part of it... You have a rather
"bad" error in that case statement... I'll just copy it here and
comment in it:
 restart)
   $0 stop
   # Initialize the test variable
   Pidval=sendmail
   ;; # <---- This line terminates the case started at the "restart)".
# Everything below this line, until the next case is just _never executed_
   # Loop as long as there's a sendmail process
   while [ "$Pidval" != "" ];
   do
         # Look for sendmail but ignore the grep
       Pidval=`ps aux | grep sendmail | grep -v grep`
       echo
       echo $Pidval
       sleep $RESTART_DELAY
   done
   $0 start
   rc_status
# This is where you should have have the double semi-colons (;;) ...

Further, some distros try to be overly clever about their sysV init
scripts, so even with that corrected, you might get some rather
non-obvious displays from those echos. But then, it really should work
OK with that fixed.
The "style" doesn't matter much, and the technique to do the waiting
is pretty standard... What you could do is "enhance" it with a
counter, so that you only iterate a set number of times (6 times would
give you three minutes).
>
> S'later...
>
> ...Kevin

Cheers
-- 
-- Glenn
email: glenn < dot > steen < at > gmail < dot > com
work: glenn < dot > steen < at > ap1 < dot > se