On Tue, 2021-01-26 at 11:33 +0100, Lennart Poettering wrote: > > > > > [Unit] > > Description=NVMe Event Monitor for Automatical Subsystem Connection > > Documentation=man:nvme-monitor(1) > > DefaultDependencies=false > > Conflicts=shutdown.target > > Requires=systemd-udevd-kernel.socket > > After=systemd-udevd-kernel.socket > > Why do you require this? > Brain fart on my part. I need to connect to the kernel socket, but that doesn't require the systemd unit. > My guess: the socket unit gets shutdown, and since you have Requires= > on it you thus go away too. That was it, thanks a lot. So obvious in hindsight :-/ Meanwhile I've looked a bit deeper into the problems accessing "/dev" that I talked about in my other post. scandir on "/" actually returns an empty directory after switching root, and any path lookups for absolute paths fail. I didn't expect that, because I thought systemd removed the contents of the old root, and stopped on (bind) mounts. Again, this is systemd-234. If I chdir("/run") before switching root and chroot("..") afterwards (*), I'm able to access everything just fine (**). However, if I do this, I end up in the real root file system, which is what I wanted to avoid in the first place. So, I guess I'll have to create bind mounts for /dev, /sys etc. in the old root, possibly after entering a private mount namespace? The other option would be to save fd's for the file systems I need to access and use opendirat() only. Right? Regards, Martin (*) Michal suggested to simply do chroot(".") instead. That might as well work, I haven't tried it yet. (**) For notification about switching root, I used epoll(EPOLLPRI) on /proc/self/mountinfo, because I read that inotify doesn't work on proc. polling for EPOLLPRI works just fine. _______________________________________________ systemd-devel mailing list systemd-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/systemd-devel