[the8472]

For the trivial case a child process would work. But ultimately docker does try to be closer to an init system or maybe screen since you can detach/attach to processes. Since reparenting to arbitrary processes is not possible in linux it's also not possible to retain the parent-child relationship for spawned containers.

If you want the fork-exec model then docker is indeed the wrong tool for the job.

[jchw]

The thing is, I don't even really like Docker as an init daemon. I have my gripes about Systemd but I see no downsides to not having a long-running daemon for a container engine. Really, whether you need root or not isn't even the most important issue; you can do sudo or suid or whatever with any container engine; Docker just has it be an implicit, unintuitive behavior.

I used to use systemd+rkt for simple container setups when I didn't need all of Kubernetes. Never noticed any downsides versus using Docker, but on the flip side, I had far fewer issues with my containers not properly starting at boot.

[paulddraper]

I read an article (can't find it now) that said from a previous project the Docker authors concluded they wanted a daemon so they didn't have to do things like file locks, etc. around image management.

Don't know if that accounts for the whole reason or not.

[jhealy]

Sounds like it might've been this article?

https://jpetazzo.github.io/2017/02/24/from-dotcloud-to-docke...?

[jchw]

Oh yeah, I read that - surrounding the original authors at dotCloud about their experiences trying to do it in multiple processes IIRC. That said, it seems the problem may be somewhat solved at this point.

[cyphar]

The reason boiled down to "it's easier to write a daemon to handle it all". But it's definitely not better than the alternative, nor is the alternative impossible.