In message <20141009152227.gq13...@mournblade.imrryr.org>,
Viktor Dukhovni <postfix-us...@dukhovni.org> wrote:
>On Wed, Oct 08, 2014 at 06:17:45PM -0700, Ronald F. Guilmette wrote:
>> As I understand it, a Postfix policy server is supposed to be reading
>> incoming requests from stdin.
>
>No, it is supposed to be accepting requests via TCP or unix domain
>socket. It can even handle multiple connections via a threaded or
>event based model.
Please do correct me if I'm wrong... I may be misunderstanding...
but these additional possibilities you are describing would be
available _only_ if the policy server is invoked by something
other than spawn(8), correct?
I wonder how many Postfix policy servers have been written to be
invoked other than via spawn(8). I have trouble imagining that any
have been, since just allowing them to be invoked by spawn(8)...
which automagically handles hooking up stdin to the proper socket...
is so marvelously convenient.
>> How exactly does one "disconnect" from stdin? I mean other than by
>> calling exit() ?
>
>One can close a file descriptor.
Well, yes, that _did_ occur to me. However within the context of the
SMTPD_POLICY_README comment I cited, I was not and am not persuaded
that that makes a lot of sense. Here is a more complete quote:
In case of trouble the policy server must not send a reply. Instead
the server must log a warning and disconnect. Postfix will retry
the request at some later time.
If an ``ordinary'' policy server, i.e. one that is invoked by spawn(8),
"disconnects" by closing its stdin, then how exactly will Postfix be
able to "retry the request at some later time"?
Perhaps more to the point, if a given running instance of a policy server
were indeed to close its stdin _without_ exiting, of what use would it
be thereafter? It's not as if stdin could be somehow re-opened once
the trouble has passed.
>However, when created by spawn(8)
>the process handles just one connection, so there is nothing left
>to do after closing the connection but exit().
Exactly my point.
>Since exit() also
>closes all files, that's enough. In particular such a server must
>also exit when a read of stdin reports EOF.
I'm glad you mentioned that, because I wanted to ask a question about
that too.
Somewhere burried in the documentation I vaguely remember seeing a
comment to the effect that Postfix will only ask a policy server to
handle 100 requests. (I guess that this is one way of allowing for
badly written policy servers that have, for example, memork leaks
or other kinds of problems that would otherwise build up over time.)
My question is just this: After Postfix has sent 100 requests to a
given running instance of a policy server, and after it has successfully
received back 100 properly formatted replies from the given policy
server instance, then what happens?
My intutive guess is that then Postfix sends an EOF to the policy
server to let it know that its tme for it to commit suicide. However
that is just an intutive guess on my part. Perhaps Postfix sends a
signal instead (?)
And, ah, while we are on _that_ subject, are there reccomendations
about what sorts of signals policy servers might likely receive and/or
about which ones they should attempt to catch and/or about what actions
they should try to take in response to various signals?
Since the one that I'm building will (so far) not be modifying any
files or data bases, or updating any oher kind of external "state"
information, I guess it's fine if it just _does not_ catch any
signals at all, and just dies ``normally'' in response to, for example,
the SIGTERM that might likely be sent to it at system shutdown time.
