Another daemon for managing control groups
Another daemon for managing control groups
Posted Jan 3, 2014 18:08 UTC (Fri) by aigarius (guest, #7329)In reply to: Another daemon for managing control groups by mezcalero
Parent article: Another daemon for managing control groups
None of these require these things to be bundled together within a single binary or project.
Init systems have communicated with udev for startup for years before systemd came along. It is trivial and elegant - you start the udev and then start a service to mount/fsck all the filesystems. This service might do the work itself or just ask udev if its done the work - none of that matters to the init. Init only needs to know when the filesystems are ready for the start of launching of other services, which is communicated by the script exiting with exit code 0.
Init system does not have to include a cgroup manager to start services in their appropriate cgroups, you can trivially provide an equivalent of cgroups-launch wrapper that would communicate with a cgroups daemon and ensure that cgroup is switched before launching the secondary executable. Init system might provide a handy shorthand, for example that if a CGRoup option is specified for a service, then it will be launched via a cgroups-launch wrapper with the CGroup contents passed on to that launcher as a parameter. Trivial, decoupled, just as functional.
And cgroups daemon can trivially provide hooks for the udev to call when devices are added or removed in the usual way. There is no need to invent some tight coupling.
Init systems have communicated with udev for startup for years before systemd came along. It is trivial and elegant - you start the udev and then start a service to mount/fsck all the filesystems. This service might do the work itself or just ask udev if its done the work - none of that matters to the init. Init only needs to know when the filesystems are ready for the start of launching of other services, which is communicated by the script exiting with exit code 0.
Init system does not have to include a cgroup manager to start services in their appropriate cgroups, you can trivially provide an equivalent of cgroups-launch wrapper that would communicate with a cgroups daemon and ensure that cgroup is switched before launching the secondary executable. Init system might provide a handy shorthand, for example that if a CGRoup option is specified for a service, then it will be launched via a cgroups-launch wrapper with the CGroup contents passed on to that launcher as a parameter. Trivial, decoupled, just as functional.
And cgroups daemon can trivially provide hooks for the udev to call when devices are added or removed in the usual way. There is no need to invent some tight coupling.
It seems that systemd developers not only "look at all that was before and found it lacking", but also at that point stopped looking and thinking outside the box that they put themselves into. Refusing cooperation with other projects and instead trying embrace-and-extend them is a huge red flag in free software communities. That never ends well.