On Tue, Oct 8, 2013 at 4:12 AM, Zbigniew Jędrzejewski-Szmek <zbys...@in.waw.pl> wrote: > 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?
I attached the service unit, socket unit, and the shell script I'm using to integrate nginx with the sabridge utility. That's part of why I didn't just send a git patch from the systemd tree alone. I forgot to note that PrivateNetwork does work in the service unit; I only disabled it to benchmark the "control" of Apache Bench directly against nginx. Here's what the script does: (1) Starts nginx (2) Waits for nginx's PID file (3) Starts the bridge A future version might integrate the first two into the bridge to streamline usage. > Why not implement this using startand epoll loop? libev uses epoll on any kernel systemd supports. The abstractions don't cost must in overhead (compared to libevent) and are useful. For example, libev bundles convenient signal trapping and can also cleanly exit on ev_unloop(). It also has thread/loop-integration facilities if we ever want to support multiple threads. > Since you're proxying all data transfered in both directions, why disallow > multiple sockets? There's no reason it couldn't scale to any number in future versions. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel