[systemd-devel] Thoughts on adapting daemons to use socket activation

[Alexander E. Patrakov]

2012/8/21 Alexander E. Patrakov <patrakov at gmail.com>:
> 2012/8/21 Lennart Poettering <lennart at poettering.net>:
>> On Sat, 18.08.12 16:04, David Strauss (david at davidstrauss.net) wrote:
>>> Additionally, socket activation could get rather interesting
>>> capability if there were a middle-ground between single process per
>>> connection and one process for all connections. Frameworks like
>>> Twisted Python and node.js have built their own wrappers to do this in
>>> various kludgy ways that involve a master process opening the main
>>> socket and then passing file descriptors or other structures into the
>>> fork()ed processes or using separate "load balancers" to spread the
>>> requests out. This might be totally out of scope for systemd, though.
>>
>> Hmm, so this would mean systemd would spawn multiple instances of a
>> service binary, but pass all of them the listening socket? Interesting
>> idea. We could probably do that, but we couldn't dynamically know how
>> many worker processes to spawn, since we wouldn't know how much entries
>> are queued unprocesse on the socket... Or maybe, there is an
>> ioctl/sockopt for that? Definitely an interesting idea...
>
> No need to configure this dynamically. This is supposed to be an
> option configured statically by the sysadmin via a configuration file
> (a service file?), just like the ServerLimit and MaxClients apache2
> config directives. And the whole things looks very much like apache2
> preform MPM.

Forgot to say: feel free to ignore the self-regulating nature of the
prefork MPM advertised at
http://httpd.apache.org/docs/2.2/mod/prefork.html. Just preforking a
fixed number of processes sharing the same listening socket is good
enough in some (most?) cases.

-- 
Alexander E. Patrakov