Is it impossible to use systemd for services that will not have a PID like docker/docker-compose/podman results?

Question

I want to systemd-ize our docker/docker-compose/podman setups, but it seems that systemd is incapable of properly dealing with service units that end without leaving a process behind. That is problematic, because the tools in question work by calling an API, scheduling processes to start but not spawning or forking them themselves, so by the time a call to, say, docker-compose returns, no processes are visible for systemd, so any variation of Type/RemainAfterExit still leads to the service marked as stop/dead/stopping/etc., because no surviving PID is detected.

I am not sure if this is relevant, but I run in userspace with --user. Lingering is enabled for the user.

This is one of my many attempts at getting systemd to work, but like any other combination of settings, it gets stopped after 5 seconds:

[Unit]
Description=%u service with docker compose
BindsTo=podman.service
After=podman.service

[Service]
Environment=DOCKER_HOST=unix:///run/user/%U/podman/podman.sock
Environment=XDG_RUNTIME_DIR=/run/user/%U
Type=oneshot
RemainAfterExit=yes
WorkingDirectory=/srv/podman/%u
ExecStart=/usr/local/bin/docker-compose up -d --remove-orphans
ExecStop=/usr/local/bin/docker-compose down -v

[Install]
WantedBy=default.target

I start above file with systemctl --user start myservice.service. It produces an output like this:

May 04 14:10:27 myhost systemd[841]: Starting myservice service with docker compose...
May 04 14:10:27 myhost docker-compose[106023]:  Container nginx  Creating
May 04 14:10:27 myhost docker-compose[106023]:  Container nginx  Created
May 04 14:10:27 myhost docker-compose[106023]:  Container nginx  Starting
May 04 14:10:27 myhost docker-compose[106023]:  Container nginx  Started
May 04 14:10:27 myhost systemd[841]: Finished myservice service with docker compose.
May 04 14:10:32 myhost systemd[841]: Stopping myservice service with docker compose...
May 04 14:12:03 myhost systemd[841]: myservice.service: Stopping timed out. Terminating.
May 04 14:12:03 myhost systemd[841]: myservice.service: Failed with result 'timeout'.
May 04 14:12:03 myhost systemd[841]: myservice.service: Unit process 106072 (docker-compose) remains running after unit stopped.
May 04 14:12:03 myhost systemd[841]: Stopped myservice service with docker compose.
May 04 14:12:03 myhost docker-compose[106072]:  Container nginx  Stopping
May 04 14:12:03 myhost docker-compose[106072]:  Container nginx  Stopped
May 04 14:12:03 myhost docker-compose[106072]:  Container nginx  Removing
May 04 14:12:03 myhost docker-compose[106072]:  Container nginx  Removed

Answer 1

When executing docker-compose from systemd you do not want to daemonize (remove the -d option from your ExecStart) so systemd can properly track it.

You probably also do not need to declare the Type= or RemainAfterExit= options as the defaults should be fine for docker-compose services.

If you want to make services for individual containers, I would advise you look at the output of podman generate systemd for one of your containers and adjust your Docker service files to be similar.

Another note: the podman.service is not supposed to be constantly running as it is invoked from podman.socket. Setting After= to reference podman.socket may be closer to the behavior you are expecting. I am not sure the BindsTo= option is what you are looking for. While the podman.socket would be required for running docker-compose commands, it is not required for running the containers and I am not sure you would want all of your containers to restart when the Podman API is restarted.

With all that, your posted service file would look like this:

[Unit]
Description=%u service with docker compose
After=podman.socket

[Service]
Environment=DOCKER_HOST=unix:///run/user/%U/podman/podman.sock
Environment=XDG_RUNTIME_DIR=/run/user/%U
WorkingDirectory=/srv/podman/%u
ExecStart=/usr/local/bin/docker-compose up --remove-orphans
ExecStop=/usr/local/bin/docker-compose down -v

[Install]
WantedBy=default.target

These have been my experiences with running podman and docker-compose through systemd. Hopefully some of that helps you craft working services for your containers.