[systemd-devel] Early review request: socket activation bridge

[Lennart Poettering]

On Thu, 10.10.13 17:39, Zbigniew Jędrzejewski-Szmek (zbyszek at 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 (zbyszek at 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.