<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 29, 2014 at 9:09 PM, Michael Scherer <span dir="ltr"><<a href="mailto:misc@zarb.org" target="_blank">misc@zarb.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Le vendredi 28 mars 2014 à 12:12 -0500, Brandon Black a écrit :<div class="">
> 4) Socket Activation! I know this is what some will scream when they<br>
> skim the above, but it's not a realistic solution in this case for a<br>
> few reasons:<br>
>     a) The startup delay, in some cases, can be many whole wallclock<br>
> seconds.  This is necessary and acceptable in the general sense (this<br>
> is network service that people use with large server-side<br>
> installations, not a desktop thing).<br>
<br>
</div>It only occurs on the first start, no ?</blockquote><div><br></div><div>No, these delays (well, for configurations large enough to involve substantial delays) will happen on every fresh start, include "restart" starts.  This means the sequential stop->start that systemd wants to do is always going to give an availability gap where no daemon is processing requests for a while.  Socket activation would keep the sockets open during that window, but the buffers would just overflow anyways and/or the eventual responses would be way too late to matter.  The command I want to execute for ExecRestart doesn't have this issue because it knows how to coordinate with itself for overlapping, so that the expensive "start" operations happen before "stop".</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="">
> socket "label" that could be accessed by the daemon via sd_* APIs to<br>
> distinguish would be useful here?<br>
<br>
</div>You can use getsockopt to get some information, and match the port/type<br>
to the appropriate structure.<br>
See <a href="https://trac.torproject.org/projects/tor/ticket/8908" target="_blank">https://trac.torproject.org/projects/tor/ticket/8908</a> for a patch<br>
doing that kind of thing for tor.<br></blockquote><div><br></div><div>What I was trying to say (perhaps very unclearly): there might be distinctions between the many sockets which getsockname() does not capture.  For a generic example: the daemon may allow the user to configure 0->N TCP sockets for HTTP and 0->M other TCP sockets for HTTPS.  The user gets to choose arbitrary port numbers for them all.  getsockname() is going to show me M+N TCP sockets on arbitrary ports, but how does the information about which was meant for which role get from user -> service unit -> actual daemon code?</div>
</div></div></div>