On 01/09/16 15:43, Roger Pate wrote:
> On Thu, Sep 1, 2016 at 8:34 AM, Laurent Bercot
> <ska-supervision_at_skarnet.org> wrote:
>> OK, now let's have a look at LISTEN_FDS.
>
> I also find these particular implementation details a poor choice. I
> was going to recommend a different environment convention, but then I
> saw the pre-existing convention was copied exactly.
>
> If I was Daniel, I'd create something better. But I'm not sure
> there's enough interest/need to warrant it. (Daemons currently
> written to expect LISTEN_FDS could have a chain-loaded conversion
> program.)
>
> Not that I'm particularly knowledgeable here; s6's fdholding seems
> able to fill this niche already.
FD holding is a very general mechanism and requires a protocol between
the FD holding daemon and the client(s). A "./run" script can access the
FD holding daemon, but this isn't the purpose of the systemd style
socket activation.
Socket activation is a very old idea in Unix and commonly implemented
the inetd superserver. This works well for forking servers with low
setup overhead. There several problems with forking one process per
connection.
* For some protocols forking a process per request is too much overhead.
* Some daemons perform expensive setup operations e.g. OpenSSH used to
generate an ephemeral SSHv1 server key during startup.
A socket requires very few resources compared to a running process
especially a process offering a non-trivial service yet only the bound
socket is required for clients to initiate a connection. This tempted
Apple to not just create and bind sockets in the superserver but also
accept the (first) connection inside the superserver before they spawn
the service process. The problem is that now the superserver has to pass
the bound socket and the accepted connected socket to the service
process. This requires a protocol between the superserver and the
service. Both Apple and systemd "strongly recommend" applications to
link against their libraries resulting in an annoying vendor lock-in.
On a classic Unix server running a few services this is unnecessary
complexity, but these days most unixoid systems are powered by a single
Lithium battery cell. Launchd went too far too quickly and the original
implementation requires Mach IPC. In a launchd world every service is
always available and the processes implementing it are spawned on
demand. There is even a transaction concept enabling launchd to reclaim
resources from cooperating services unless they're inside a transaction.
This design works well on a laptop or smartphone. It fails spectacularly
in the face of "evil legacy software" which doesn't follow the "one true
way".
The systemd APIs look like they try to follow a middle ground, but they
end up making a mess out of things. Have a look at
https://ewontfix.com/15/ if want to know more about systemd's design flaws.
Received on Thu Sep 01 2016 - 15:02:04 UTC