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