[systemd-devel] How do I find out why a service was started? (systemd-tmpfiles-setup failed in container)

[Johannes Ernst]

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)