[systemd-devel] [PATCH 1/3] core: Add LISTEN_NAMES environment variable

[Lennart Poettering]

On Mon, 18.05.15 10:19, Richard Maw (richard.maw at codethink.co.uk) wrote:

> On Sat, May 16, 2015 at 09:28:22PM +0000, Zbigniew Jędrzejewski-Szmek wrote:
> > Why it the motivation? Patch description talks tabout passing the
> > path/address in LISTEN_NAMES. Isn't this something that can be queried
> > already? TODO talks about "identifiers". Is "identifier" the same thing,
> > or did the TODO item about have some different meaning?
> 
> I assumed that since the TODO came about at roughly the same time that systemd
> gained the ability to hold onto fds for services while they restarted, that
> this would be a way to identify the purpose of returned file descriptors
> without having to store a mapping of the inode number and device number to fd
> purpose into /run.
> 
> The provided patch doesn't add a way to pass an identifier for a fd to systemd
> though so if that were the motivation, then this patch wouldn't be
> sufficient.

The TODO list item is purely about adding manual identifiers to fds,
it's not about adding type information to them: the kernel already
carries enough type information for us, the only problem is that
sometimes the type alone is not enough, we want to properly give the
fds a label.

This has a number of usecases. One of them is this: logind wants to
store fds referring to DRM or input devices in PID 1, so that it can
be restarted at any time without losing access to the DRM/input
devices it manages. Now, if you have multiple sessions that access the
same devices, then each of the fds referring to these DRM/input device
nodes look pretty much the same: their fstat() data is identical,
their /proc/self/fd/<fd> symlink is the same, hence it's impossible to
figure out which fd belongs to which session simply by looking at them
with fstat() and /proc.

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...

The names are useful in other cases too: if you have a daemon that
listens on two protocols at the same time (let's say POP3 and IMAP4)
on different ports, but not necessarily use the standard ports. hence
you need a nice way during actviation to let your daemon know which
one to use for which... (so far this was solved by having
configuration also for the daemon that then maps the ports back to the
protocol, but using ids for this is nicer, as it requires only one set
of configuration).

I hope that makes sense as rationale. The TODO list item is really
about labelling fds, not about attaching type info to the fds.

Lennart

-- 
Lennart Poettering, Red Hat