Hey Martin, thanks, but:
>> My container is degraded because systemd-tmpfiles-setup.service >> failed. My understanding is that it should not run in the container >> anyway. (Right?) > > It should run in a container; its purpose is both necessary, and I > don't see why a container would have any difficulty with it. It runs > just fine in both system and even unprivileged user containers here. Here is what fails: # /usr/bin/systemd-tmpfiles --create --remove --boot --exclude-prefix=/dev Failed to create file /sys/devices/system/cpu/microcode/reload: Read-only file system This is systemd 221 on Arch in a container straight from the man page, just in case I screwed up my own, but the behavior is the same. # pacstrap -c -d $(pwd)/arch-tree base # systemd-nspawn -bD $(pwd)/arch-tree/ >> How do I find out why it was started? > > $ systemctl list-dependencies --reverse systemd-tmpfiles-setup.service > systemd-tmpfiles-setup.service > ● └─sysinit.target This analyzes the static dependencies (and does indeed solve my problem here, thanks! I had missed the —reverse flag), but I was wondering whether there was something more dynamic that could tell me something like: a.service started, because b.service required it b.service started because user foobar started it > > "systemctl status systemd-tmpfiles-setup.service" will say that it's > statically enabled, and the list-dependencies says where. I. e. you > should have a symlink > /usr/lib/systemd/system/sysinit.target.wants/systemd-tmpfiles-setup.service > > (could also be in /lib/systemd/, depending on your distro) > > Martin > > -- > Martin Pitt | http://www.piware.de > Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
