> you’ll see a WantedBy line. This is a great place to set up container dependencies. In this example, the container that runs caddy (a web server) can’t start until Wordpress is up and running.
Either this must be some systemd weirdness that I thankfully haven't had to deal with until now, or I'm misunderstanding something.
Did I understand correctly you don't specify which services you need but rather which ones depend on your service? So if your service doesn't start you'll need to check the configuration files of all other services to figure out which dependency is preventing it from starting?
This is the mechanism by which one unit can ask to be added to the Wants= of another when it is installed.
i.e., when you run 'systemctl enable whatever.service', it will be symlinked into '/etc/systemd/system/multi-user.target.wants'. And 'systemctl show multi-user.target' will show 'whatever.service' in its Wants property.
During bootup of a headless system, the 'default' target is usually multi-user.target, so what we've done here is ensure that whatever.service will be started before the machine finishes booting.
I think it's a bit of a Podman quirk. From what I understand, podman used (and is probably still able) to generate systemd .service files. These files do have Requires and After commands, to state which other services they expect. However, Podman has since moved to using the .container file for systemd "units", which was meant to represent an transient, disposable instance but in practice reproduces a lot of what .service specifies. Probably because people didn't want to do the work twice, they tacked on an [Install] section to .container to make it behave like a service, which currently accepts only the keywords Alias, RequiredBy and WantedBy (I've not seen any documentation on how these differ) according to https://docs.podman.io/en/latest/markdown/podman-systemd.uni...
This are standard systemd service file syntax and standard systemd directives. Quadlet forwards everything but the [container] section directly to the generated service file.
Systems scans all of the unit files initially, and topologically sorts them to find the best start ordering for all services. Unit files are rescanned only when you run systems daemon-reload.
One of its main design goals is a fast system startup, to do that it does need know the dependency ordering of all services.
It's not how you would normally specify it, but it is an option: the normal usage for it in systemd is enabling and disabling which services start on boot: an enabled service usually gets set up as a dependency of the multi-user target which is what systemd starts on boot. (And you can get a list of dependencies from systemd if you want to debug anything: the WantedBy stuff just turns into some symbolic links in the filesystem if you want to inspect things manually)
I don't know why it's being used in that way for these containers. It'd be easier to just add a Wants line on Caddy.
You can define Before, After, or WantedBy to define the dependency order. Systemd them makes sure to start services in the right order, it starts them by default but you can also configure services not to start if nothing depends on them.
Either this must be some systemd weirdness that I thankfully haven't had to deal with until now, or I'm misunderstanding something.
Did I understand correctly you don't specify which services you need but rather which ones depend on your service? So if your service doesn't start you'll need to check the configuration files of all other services to figure out which dependency is preventing it from starting?