<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Feb 18, 2016 at 9:08 AM, Lennart Poettering <span dir="ltr"><<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Wed, 17.02.16 17:44, Ben Woodard (<a href="mailto:woodard@redhat.com">woodard@redhat.com</a>) wrote:<br>
<br>
> Is it intentional that systemd holds a reference to a socket it has<br>
> just accepted even though it just handed the open socket over to a<br>
> socket.activated service that it has just started.<br>
<br>
</span>Yes, we do that currently. While there's currently no strict reason to<br>
do this, I think we should continue to do so, as there was always the<br>
plan to provide a bus interface so that services can rerequest their<br>
activation and fdstore fds at any time. Also, for the listening socket<br>
case (i.e. Accept=no case) we do the same and have to, hence it kinda<br>
is makes sure we expose the same behaviour here on all kinds of<br>
sockets.<br></blockquote><div><br></div><div>I'm having trouble believing that consistency of behavior is an ideal to strive for in this case. Consistency with xinetd's behavior would seem to be a better benchmark in this case.</div><div><br></div><div>And I'm not sure that I understand the value being able to rerequest a fdstore of fds. To me this sounds like it would be a very rarely used feature. Could this be made an option that could be enabled when you add the bus service that allows a service to rerequest their activation and fdstore fds?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Did you run into problems with this behaviour?<br></blockquote><div><br></div><div>Oh yes. It breaks a large number of management tools that we have on to do various things on clusters. It is a kind of pseudoconcurrency. Think of like this:<br></div><div><br></div><div>foreach compute-node;</div><div>   rsh node daemonize quick-but-not-instant-task</div><div><br></div><div>With xinetd the demonization would close the accepted socket.  Then the foreach loop would nearly instantly move onto the next node. We could zip through 8000 nodes in a couple of seconds.</div><div><br></div><div>With systemd holding onto the socket the "rsh" hangs until the quick-but-not-instant-task completes. This causes the foreach loop to take anywhere from between 45min and several hours. Because it isn't really rsh and demonize and I just used that to make it easy to understand what is going on, rewriting several of our tools is non-trivial and would end up violating all sorts of implicit logical layering within the tools and libraries that we use to build them.</div><div><br></div><div>Where is this in the source code? I've been planning to send you a patch to change the behavior but I have't quite connected the dots from where a job within a transaction is inserted on the run queue to where the fork for the "ExecStart" actually happens.  </div><div><br></div><div>-ben</div><div>Red Hat Inc.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Lennart<br>
<br>
--<br>
Lennart Poettering, Red Hat<br>
</font></span></blockquote></div><br></div></div>