On 9 December 2014 at 17:28, Lennart Poettering <lenn...@poettering.net> wrote: > On Tue, 09.12.14 16:24, Krzysztof Kotlenga (k.kotle...@sims.pl) wrote: > >> 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? > > Hmm, but what would you do for a service that has both PrivateNetwork > and chroot enabled? > > I am all open for shifting things around again, but I inda would > prefer a solution that works universally in the end... > > Ideas? > > I figure we could open a new mount namespace and mount the file system > socket into the chroot, but not sure I like the idea...
I don't know what is the best solution but using a socket file seems better than using an abstract unix socket: processes in a systemd-nspawn container could discover the notify socket of the host in /proc/net/unix (if it does not use a new network namespace) and send garbage file descriptors with SCM_RIGHTS from the container to the host. Systemd on the host does the right thing: it closes the fds when the datagram was not sent by a managed unit. Does manager_get_unit_by_pid() matches the exact cgroup path only or does it also matches a prefix path? I wonder about nspawn containers started by a service unit on the host. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel