On Thu, 10.10.13 17:39, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:
> > On Thu, Oct 10, 2013 at 05:08:26PM +0200, Lennart Poettering wrote: > > On Tue, 08.10.13 13:12, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) > > wrote: > > > > > > > > On Tue, Oct 08, 2013 at 02:07:27AM -0700, David Strauss wrote: > > > > I've attached the initial implementation -- not yet ready to merge -- > > > > for an event-oriented socket activation bridge. It performs well under > > > > load. I haven't tied up all potential leaks yet, but the normal > > > > execution paths seem to be clean. I also need to use proper shell > > > > option management. > > > Hi David, > > > > > > how do you intend target service to be started? I understand that the > > > intended use case case is for non-socket-activatable services, so they > > > should be started synchronously in the background. In case of local > > > services normal systemd management (over dbus) would work. In case of > > > remote systems, maybe too, if dbus over the network was properly > > > authorized. Do you havy any plans here? > > > > For local systems it should be sufficient to simply invoke the backend > > service as dependency of the proxy instance. i.e. not need to involve > > D-Bus just activate the backend service at the same time as the socket > > activated proxy service. Or am I missing something? > Yeah, that would be enough. I was confused by that idea that we want > to delay the starting of the target service. But we don't have to do that, > because the proxy service is itself socket activated and started when > we actually have a connection. > > If the target process is managed by systemd, the target service should > be bound to be started and stopped together with the proxy service. If > systemd.unit(5) is correct, this could be expressed as combination of > BindsTo=<proxy.service> and PartOf=<proxy.service>. > > One thing which we can't make work currently, is having the target > service managed by systemd, but running with PrivateNetwork=yes. In > this case, the bridge process must be inside of the target service > and start the target binary itself. But maybe that's not so bad, > since the proxy can be introduced by adding one word to ExecStart=. Hmm, that's actually a good idea. The tool should have a mode wher you can prefix the command line of another daemon with an invocation of this tool. It would then fork the proxy bit into the background, and use PR_SET_PDEATHSIG to make sure it will die along with the process it is the proxy for. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
