[systemd-devel] Notification socket and chroot vs PrivateNetwork conflict (abstract vs file-system)

[Krzysztof Kotlenga]

Hi.

Currently notify socket is unavailable in chrooted services (again)
unless you bind mount it there. Is there perhaps another, less
cumbersome way?

So far notify socket was:
1. abstract socket

   commit 8c47c7325fa1ab72febf807f8831ff24c75fbf45
   notify: add minimal readiness/status protocol for spawned daemons

2. file-system socket

   commit 91b22f21f3824c1766d34f622c5bbb70cbe881a8
   core: move abstract namespace sockets to /dev/.run

   Now that we have /dev/.run there's no need to use abstract
   namespace sockets. So, let's move things to /dev/.run, to make
   things more easily discoverable and improve compat with chroot()
   and fs namespacing.

3. abstract socket again

   commit 29252e9e5bad3b0bcfc45d9bc761aee4b0ece1da
   manager: turn notify socket into abstract namespace socket again

   sd_notify() should work for daemons that chroot() as part of their
   initilization, hence it's a good idea to use an abstract namespace
   socket which is not affected by chroot.

4. file-system socket again

   commit 7181dbdb2e3112858d62bdaea4f0ad2ed685ccba
   core: move notify sockets to /run and $XDG_RUNTIME_DIR

   A service with PrivateNetwork= cannot access abstract namespace
   sockets of the host anymore, hence let's better not use abstract
   namespace sockets for this, since we want to make sure that
   PrivateNetwork= is useful and doesn't break sd_notify().


So... would it be acceptable to have two notify sockets, one abstract
and one normal, the latter only set for services with PrivateNetwork
or - better maybe - explicitly selectable? Any other ideas?

-- 
K.