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

Krzysztof Opasiak k.opasiak at samsung.com
Mon May 18 07:37:02 PDT 2015

On 05/16/2015 11:28 PM, Zbigniew Jędrzejewski-Szmek wrote:
> On Fri, May 15, 2015 at 05:35:48PM +0200, Lennart Poettering wrote:
>> On Fri, 15.05.15 17:09, Krzysztof Opasiak (k.opasiak at samsung.com) wrote:
>>> When passing file descriptors to service systemd
>>> pass also two environment variable:
>>> - LISTEN_PID - PID of service
>>> - LISTEN_FDS - Number of file descriptors passed to service
>>> Passed fds may have different types: socket, fifo etc.
>>> To distinguish them sd-daemon library provides a set of
>>> sd_is_*() functions which does stat on given fd and path
>>> and check if this fd is relaten with this path.
>>> This commit adds third environment variable:
>>> - LISTEN_NAMES - paths/addresses of passed fds
>>> this variable consist of fds names separated by :.
>>> Each fd name consist of two parts:
>>> fd_type=fd_address
>> Why do we need the type at all? It can always be derived from the fd
>> anyway, so why specify?
> 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?

Not exactly. As far as I know it is not possible to get for example fifo 
path when you have only file descriptor.  So it is not possible to ask 
what is fifo path for this fd? but you may only ask if this path related 
with this fd? Currently it is done by doing stat on fd and stat on path 
and compare the results.

If we pass this data in env we don't need to do stat on path but only do 
strcmp() (path cmp exactly, because /a/b/c is equal to /a////b///c).

As far as I understood Lenart doing last hackfest paths are understood 
as identifiers but Lenart please correct me if I misunderstood something.

Krzysztof Opasiak
Samsung R&D Institute Poland
Samsung Electronics

More information about the systemd-devel mailing list