[nos-bbs] Message log jam

[Michael E Fox - N6MEF]

Good to know, but I don't think this was my situation.

The one time I saw mqueue was backed up and nothing was moving, I restarted
JNOS.  (I didn't think of "smtp kick" at the time).  After JNOS restarted,
messages started flowing again.  Also, the stuck messages had not been
returned to sender, as they should have been if they are undeliverable.  So
it's as if the SMTP process within JNOS was hung or dead, not just the top X
messages were unable to be delivered.  

So, at least in my case there's something else at work here.  

Still, if "smtp t4" is less than "smtp timer", then the queue should give up
on a dead connection and move on to the next message, not stop.  If it's
doing that, then that's bad.   Those that are having log-jam problems might
want to make sure that "smtp t4" (outbound timeout) and "smtp tdisc"
(inbound timeout) are significantly less than "smtp timer" so the queue has
time to give up on bad connections and move on before the next cycle starts.

Michael
N6MEF

-----Original Message-----
From: nos-bbs-bounces at tapr.org [mailto:nos-bbs-bounces at tapr.org] On Behalf
Of Jay Nugent
Sent: Friday, March 21, 2014 12:25 PM
To: TAPR xNOS Mailing List
Subject: Re: [nos-bbs] Message log jam

Greetings,

On Fri, 21 Mar 2014, Wm Lewis wrote:

>
> Tried SMTP KICK (Nothing happened)
> Removed any 'lck' files, and re'kicked' (nothing happened)
> Removed all files except the sequence file, (in /jnos/spool/mqueue) then
waited. New messages instantly jam again.
> Rebooted. No change, instant jam.
>
> Only thing that seems to get them going again is if I delete all files 
> in /jnos/spool/mqueue *and* all files in /jnos/spool/mail
>
> Of course deleting the later files mean deleting every last message on 
> my system. Not really the course of action I'm looking for.
>
> So, as of now, they are still back-logging in the /jnos/spool/mqueue 
> directory waiting for some unknown force to kick in.


    If there are several messages stuck in the queue, and let's say that 3 
of them cannot reach their destination, then those 3 will remain at the 
top of the queue and block ALL REMAINING MESSAGES from being delivered. 
JNOS does NOT push undeliverable messages to the back of the queue :(

    What controls how many messages are allowed to be in transit 
simultainiously is "SMTP MAXCLIENTS".  In my scenario above, if this is 
set to 3 then the undeliverable messages will block all others in the 
queue.  If we up the SMTP MAXCLIENTS to 4, then the 4th msg in the queue 
will be allowed to fly.  Once it is completed the next message (now the 
new fouth message) will fly.

    But when you encounter a 4th message that is undeliverable, the queue 
will again be jammed :(

    What we need is for the queue to push "undeliverable" messages to the 
rear of the queue.  Let the messages that CAN be delivered get moved 
toward the front of the queue and get sent.  Whether we rear-queue 
undeliverables after one try, or two, or three might be open for 
discussion.


       ---- Jay Nugent  WB8TKL
            Hamgate.Washtenaw.AMPR.org