Problems posting articles when server is paused

Julien ÉLIE julien at trigofacile.com
Sun Mar 15 15:32:54 UTC 2009


Hi Ray,

> I have come across a nasty problem when people try to post while the server is paused for some reason.

Sorry for the delay...


> Whenever the xref master server is paused when users try to post,
> the client connection will eventually time out, telling the users that their post failed, while the article has actually been 
> queued and will be accepted as soon as innd is un-paused again.

It appears that innd does not answer to IHAVE requests when paused
(it waits for being in its running mode before responding).  Therefore,
nnrpd waits too...  As soon as the server is unpaused, innd posts it
and nnrpd receives the answer.
When the server is throttled, innd directly answers 400 and nnrpd spools
the message.


> Is there some setting I can use to prevent this highly disruptive problem (other than setting spoolfirst = true)?

Unfortunately nothing.


> If there isn't, is this behaviour desired or is it a bug?

A bug.


> I have reproduced this problem by just sending a ctlinnd pause ''

Hmm...  A non-empty reason is necessary for the news server to pause.

16:11 news at trigo ~% ctlinnd pause ''
ctlinnd: Empty reason
zsh: exit 1     ctlinnd pause ''


> to innd and then trying to post and I did not see the queued article show up in $pahtspool/outgoing. Where is this article 
> actually queued and how long does nnrpd wait for innd to accept the article before it puts it in the outgoing directory for rnews 
> to process it later on?

It would have been in <pathspool>/incoming; nnrpd hangs until innd answers.
If innd answers something different than a reject, nnrpd spools it and
"rnews -U" will try to deal with it later.


I have attached a patch which I hope work well for you.  Could you please
try it and report whether it corresponds to the behaviour you wanted?
Patch for innd/nc.c.

I have implemented the following responses:

AUTHINFO, HELP, LIST, MODE, QUIT, XBATCH : still working

HEAD, STAT : 403 (impossible to carry out the action) when paused
             400+exit when throttled

CHECK : 431 (try again later) when paused
        400+exit when throttled

TAKETHIS : 403 (impossible to carry out the action) when paused
           400+exit when throttled

IHAVE : 436 (try again later) when paused for the first and second stages
        400+exit when throttled


Feel free to tell me if it is not the right thing to do.
I think we do no harm if we do not close the connection after every
command when the server is throttled.
Better send 403 than 430 (no article with that message-ID) for HEAD and STAT,
which was the previous behaviour.

As for TAKETHIS, there is no return code for deferring the article.  I chose 403.
On no account should we answer a reject in such a case for TAKETHIS.

-- 
Julien ÉLIE

« Il n'y a que le premier pas qui coûte. » (Mme du Deffand) 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pause-throttled-innd.diff
Type: application/octet-stream
Size: 4496 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/inn-workers/attachments/20090315/36d603db/attachment.obj>


More information about the inn-workers mailing list