[systemd-devel] Early review request: socket activation bridge
Zbigniew Jędrzejewski-Szmek
zbyszek at in.waw.pl
Thu Oct 10 08:39:55 PDT 2013
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=.
Zbyszek
More information about the systemd-devel
mailing list