Hacker News Reader

Comment by spenczar5 | Hacker News Reader

They don’t quite do the same things. Systemd will do stuff like ensure the service is restarted if it ever crashes. It can also make sure system-level dependencies are up and running (“service B depends on service A, so wait for A to be up before trying to start B”).

Performance is not an issue in most docker setups you would ever use, correct.

View on HN

Acutally, there are docker-compose primitives that solve just that (restart: always/on-failure and depends-on: servicename.

I think it mostly comes down to what layer of abstraction you like working at.

Podman can generate systemd units for managing containers IIRC.

Yep, that's right: https://docs.podman.io/en/latest/markdown/podman-generate-sy...

Problem is you can't have it depend on anything outside of docker i.e. I can't write a docker-compose file that waits for an NFS mount.

True, Docker-compose has a lot more overlap with systemd.

But it doesn’t have system-level dependencies. For example, in systemd I can wait for a network interface to be up and have an IP assigned by DHCP. As far as I am aware, docker compose knows about the docker network and its own containers, but not the system more broadly.

Also, you will likely want it to run for a long time, so something has to trigger the docker-compose process to start and restart it. You might want it to restart in case the OOM killer knocks it over. That daemom stuff is what systemd is good for.

Reply on news.ycombinator.com