On Thu, Oct 09, 2014 at 10:07:21AM -0700, Ronald F. Guilmette wrote:
> 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?
Yes.
> 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.
Simple interfaces for sites that don't need high performance or
shared state across multiple connections. I've written policy
services that are not spawn based. I don't have a deployment survey
handy.
> 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"?
Spawn launches a new process for each new connection. If processes
launched by spawn don't exit after closing a connection, you
eventually run out of memory for processes. Common sense applies.
> 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.
You've deduced out how to apply the logic to spawn(8) managed
processes. It is expected that others can do likewise.
> 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.)
A policy server connection never outlives the smtpd(8) process that
is its client. The number of requests depends on max_use, the
number of requests per mail transaction (per RCPT requests for
example) and the number transactions per connection. There is no
default absolute ceiling. The 100 is just an approximation.
> 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?
The answer is obvious. If there is an explicit request limit set,
then the client disconnects, and the policy service sees EOF.
> 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 (?)
The simplest and clearly correct approach is to disconnect.
> 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?
Don't let your imagination carry you away...
> 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.
There you go, common sense.
--
Viktor.
