5 ms·
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 shou
by 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 agoAuto-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 agoAnd you'd be wrong... The init system will always be a daemon, for obvious reasons ;-)
- isostatic 7y agoYou're begging the question that systemd should be the init system
- oblio 7y agoI'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 agoSystemd not being a daemon doesn't make any sense; both it and SysV are init systems which are by necessity daemonized processes.
- majewsky 7y agoWell technically PID 1 is not a daemonized process because there is no one who could have daemonized it.
- weberc2 7y agoThat’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 agoWell, 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.