[systemd-devel] Revisiting the "ExecRestart" issue

[Michael Scherer]

Le vendredi 28 mars 2014 à 12:12 -0500, Brandon Black a écrit :
> 
> Hi all,
>    I've brought this up before, but I became busy/discouraged and
> dropped the ball.  As systemd becomes increasingly widely deployed, I
> can no longer afford to do so, so I'd like to explore this area a bit
> further on the list again and see if we can't come up with a workable
> solution, or if perhaps I've missed some systemd/cgroups change in the
> past year or so that already allows a workaround.
>
> [.. snip .. ]
>
> 4) Socket Activation! I know this is what some will scream when they
> skim the above, but it's not a realistic solution in this case for a
> few reasons:
>     a) The startup delay, in some cases, can be many whole wallclock
> seconds.  This is necessary and acceptable in the general sense (this
> is network service that people use with large server-side
> installations, not a desktop thing).

It only occurs on the first start, no ?


>     b) The primary socket traffic we care about is UDP, and further we
> *really* care about request->response latency for this traffic.  Even
> if you could set a large enough receive buffer to handle several
> seconds of heavy UDP requests (and you can't, for at least some
> installations), the multi-second-delay in the responses isn't
> reasonable.

Again, that's a multiple second delay only for the first start, after,
this will be the regular way since the socket is directly used by the
daemon.


>     c) Another side-point that might be better addressed in another
> thread: even if both of the above weren't true, this daemon uses
> several sockets for multiple "roles" internally, some of which share
> all low-level details (e.g. two distinct use-cases for multiple TCP
> sockets that serve different high-level protocols, where the user
> might choose arbitrary ports for both).  I'm not seeing any trivial
> way to distinguish these via socket activation - perhaps some kind of
> socket "label" that could be accessed by the daemon via sd_* APIs to
> distinguish would be useful here?

You can use getsockopt to get some information, and match the port/type
to the appropriate structure.
See https://trac.torproject.org/projects/tor/ticket/8908 for a patch
doing that kind of thing for tor. 


-- 
Michael Scherer