On Mon, 18.05.15 17:55, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote:

> On Mon, May 18, 2015 at 06:01:10PM +0200, Lennart Poettering wrote:
> > Being able to attach a name to the fds is hence really useful. logind
> > could use this to attach the session identifier to the fds, and would
> > hence be able to safely map the fds back to their sessions after
> > coming back from a restart...
> Yeah, that makes sense. But currently there's no proposal how to specify
> those identifiers. Would be nice discuss both sides of the proposal at
> the same time.
> 
> sd_pid_notify_with_fds() would probably have to be extended to be
> sd_pid_notify_with_fds2(pid_t pid, int unset_environment, const char
> *state, const int *fds, const char* const *names, unsigned n_fds)

Hmm, nah. I think we can avoid adding a new call. Instead we should
explicitly allow non-unique names, and then simply pass the name to
use in a normal sd_notify_with_fds() text field, so that it is applied
to all fds pushed the same way. If you want to send multiple fds with
different ids, then one would do this with multiple
sd_pid_notify_with_fds() invocations.

Example:

        sd_pid_notify_with_fds(0, false, "FDSTORE=1\nFDNAME=foobar", (int[]) { 
STDIN_FILENO, STDOUT_FILENO }, 2);

This would push stdin and stdout of the client into PID 1 and label
both of them "foobar". On next invocation the process would then see:

        LISTEN_FDS=2
        LISTEN_NAMES=foobar:foobar
        
> And what about socket units: we could automatically generate identifiers
> like blah.socket-1, foo.socket-1, foo.socket-2 to allow sockets from multiple
> socket files be distinguished. In principle this could be made configurable
> through a new option, but I don't think it's worth the trouble.

I'd add a new option for this:

        FileDescriptorName=waldi

would apply to all fds declared with a .socket unit. If you want to
apply distinct names to multiple fds, you should define them in two
seperate .socket units.

Hope that makes sense?

Lennart

-- 
Lennart Poettering, Red Hat
_______________________________________________
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Reply via email to