On Sun, 24.11.13 16:47, David Strauss (strau...@kemper.freedesktop.org) wrote:
> TODO | 1 > man/systemd-socket-proxyd.xml | 80 > ++++++++++++++++++++++++++++++++++++++- > src/socket-proxy/socket-proxyd.c | 63 ++++++++++++++++++++---------- > 3 files changed, 121 insertions(+), 23 deletions(-) > > New commits: > commit adcf4c81c58511b67644e17fa743d1729d3c9ccf > Author: David Strauss <da...@davidstrauss.net> > Date: Mon Nov 25 10:44:48 2013 +1000 > > socket-proxyd: Add --listener option for listener/destination > pairs. Could you please explain what the usecase here is? Why is this better than having two socket units with two proxy services? > +/usr/bin/systemd-socket-proxyd --listener=3 localhost:8080 & > +/usr/bin/systemd-socket-proxyd --listener=4 localhost:8443 & > +wait]]> If our examples suggest that people should write shell scripts that fork things, then this is usually an indication that we need to rethink what we are doing here. In fact, running multiple manually forked off processes inside the same service already sounds very wrong. We should try to keep a 1:1 mapping between processes we fork and services they run it. What's the usecase here? If this is about running multiple things in the same Network namespace, then there are certainly other, better ways to achieve the same. For example, we could introduce JoinPrivateNetwork=$SERVICE or so which would allow one service to join the network namespace of another. That makes this much smoother and more powerful, too. With that in place you could simply have three proxy instances, and make them join the private network of your nginx instance and you should be set? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel