6 ms·

>Anyway, I didn’t necessarily blame Docker for it, but it did add force to an argument I’d heard before: Why does Docker need a daemon at all?

tyingq 7y ago
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.
argd678 7y ago
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.
- tyingq 7y ago
  Auto-restart isn't even default behavior though. I'd argue for "start a daemon when needed behavior."
- isostatic 7y ago
  > you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too. You certainly could.
  - oblio 7y ago
    And you'd be wrong... The init system will always be a daemon, for obvious reasons ;-)
    - isostatic 7y ago
      You're begging the question that systemd should be the init system
      - oblio 7y ago
        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.
- tpush 7y ago
  Systemd not being a daemon doesn't make any sense; both it and SysV are init systems which are by necessity daemonized processes.
  - majewsky 7y ago
    Well technically PID 1 is not a daemonized process because there is no one who could have daemonized it.
  - weberc2 7y ago
    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.
    - tpush 7y ago
      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.

tyingq 7y ago

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.

argd678 7y ago

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.

tyingq 7y ago
Auto-restart isn't even default behavior though. I'd argue for "start a daemon when needed behavior."
isostatic 7y ago
> you could argue systemd shouldn’t be a daemon too and sysv init scripts are better too. You certainly could.
- oblio 7y ago
  And you'd be wrong... The init system will always be a daemon, for obvious reasons ;-)
  - isostatic 7y ago
    You're begging the question that systemd should be the init system
    - oblio 7y ago
      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.
tpush 7y ago
Systemd not being a daemon doesn't make any sense; both it and SysV are init systems which are by necessity daemonized processes.
- majewsky 7y ago
  Well technically PID 1 is not a daemonized process because there is no one who could have daemonized it.
- weberc2 7y ago
  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.
  - tpush 7y ago
    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.