I am similarly confused as to why docker needs a daemon. For what's provided in the API, I don't see the need...it could all happen in the client.

Contrast with LXD. It has a daemon as well, but it tracks containers and state across multiple hosts, so the need is obvious. The single host LXC doesn't have a daemon.

Well for one, it can restart the container when it fails or on boot up. I don’t see how having no process minder improves anything, you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.

> you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too.

You certainly could.

And you'd be wrong... The init system will always be a daemon, for obvious reasons ;-)

You're begging the question that systemd should be the init system

I'm not. The original questions were:

> systemd shouldn’t be a daemon too

A. False.

> and sysv init scripts are better too

B. Debatable, but the start is a false premise, SysV init was a daemon plus the scripts.

Systemd not being a daemon doesn't make any sense; both it and SysV are init systems which are by necessity daemonized processes.

Well technically PID 1 is not a daemonized process because there is no one who could have daemonized it.

That’s the point. The same principle applies to Docker. Although conceivably the daemon could be just about process/container management instead of image management as well.

Well, the argument that Red Hat makes is that there already is systemd as a daemon for process management; all other functionality that docker provides does not necessitate a daemon. Thus Podman, Buildah etc.

Auto-restart isn't even default behavior though. I'd argue for "start a daemon when needed behavior."