> would you mind explaining why you do not like socket-activated style?

It's not that I don't like it, it's that I don't think it belongs in

Recall that init must be rock solid -- a crashed init brings your whole
system down.  Socket-based activation is a rather complex task -- there
are at least two strategies for socket-based activation, with different
performance/complexity tradeoffs, for both UDP and TCP --, and even so,
it will need more complexity in the future in order to avoid race
conditions and to deal properly with things such as daemons that listen
on both UDP and TCP.

But there's no reason at all why socket-based should be done by init --
all inits other than systemd do it in an independent process (inetd,
rpcbind, etc.).  The socket-activation daemons are welcome to crash --
try to stop inetd on your system, everything else still works.
Additionally, multiple socket-based activation daemons can be running at
the same time (think inetd and rpcbind on the same system).

Aside: there are other modes of process activation, that also don't
belong in init: cron and acpid are the obvious examples.  (That's a snip
at Apple, in case you didn't notice.)

Finally, I'm not convinced that socket-based activation is needed in the
first place.  In the olden times, inetd was implemented in order to
avoid having too many idle processes hanging around; nowadays, I've got
200 idle processes running on my pocket calculator, having an extra 20
daemons running on my server is really not a big deal.

-- Juliusz

All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
Polipo-users mailing list

Reply via email to