Hacker News new | ask | show | jobs
by paulddraper 2523 days ago
Yep. I only half care about rootless. I definitely care about the daemon.

It sucks.

It flies in the face of traditional Linux process management where child processes are child processes.

(Unless you want an init system, where you need a daemon. But docker is a sucky init system.)

Docker breaks even the most basic things.

    $ time docker run some heavy computation
Oh wait, that doesn't work.
2 comments

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.

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.

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.

Sounds like it might've been this article?

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

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.
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.
In that case you can use LXC or even runc directly. I wanted to (for a long time) decouple the systemd dependency from rkt, because they had the perfect model for it. Unfortunately we've all migrated to arguing about containerd vs cri-o/podman.