This whole debate saddens me

Posted Dec 3, 2014 17:38 UTC (Wed) by jb.1234abcd (guest, #95827)
In reply to: This whole debate saddens me by Cyberax
Parent article: The "Devuan" Debian fork

> That's entirely different discussion. I would even support an effort to make sure that systemd does not regress on supporting alternatives to its components."

Good to hear.
How about an alternative to what systemd proposed for managaement of cgroups (that is, a systemd, pid=1 dependent solution).
How about systemd learning to live and cooperate in an ecosystem that is based on UNIX philosophy ?

And let's stop useless discussions about SysV vice systemd becuase they
lead nowhere. Let's look into the immediate future, but not only according to systemd zealots.

This is systemd's view of cgroups management:
http://lwn.net/Articles/575793/

This is an alternative view:
A control group manager (CGManager)
http://lwn.net/Articles/618411/
Its heritage is known to be management of "task containers", extended to
resources, and renamed to control groups.

Here are some excerpts from discussion on osnews.com, in context of Devuan fork of Debian and its pending choice of a default, progressive init sys like perhaps OpenRC or uselessd (when ready) as coexisting alternatives to systemd:

by Alfman on Fri 28th Nov 2014 16:30 UTC in reply to "RE: Interesting"
"Systemd fixed real limitations of sysv init scripts, which I think is great. However it introduced excessive coupling between unrelated services, which is both unnecessary and harmful to alternatives. When programming, unnecessary coupling is often a sign of a bad design. With Lennart P, I don't suspect incompetence, therefor I worry that it's being done deliberately as part of a strategy to exclude alternatives."

Alfman on Fri 28th Nov 2014 22:52 UTC in reply to "RE[3]: Interesting"
"I disagree with this [edit: systemd's view http://lwn.net/Articles/575793/], the easiest way to do this hasn't changed with systemd. The monitoring process need only handle the SIGCLD signal. Not only is this very easy to do, but it doesn't need any special permissions or non-standard configurations either.

The link points out some functional overlap between a "cgroup manager" and a service manager. However I think that maybe cgroup management might be better left to something more powerful & flexible like linux containers. We can deploy a service inside a linux container and then allow the init system to monitor the container.
[edit: my emphasis]
This method of managing cgroups should work with any service BTW, not just ones that are designed for systemd. It should also work with any init system. This is where the power of *nix comes from in the hands of power users, not monolithic solutions."
[edit: my emphasis][end]

by Alfman on Sat 29th Nov 2014 08:36 UTC in reply to "RE[6]: Interesting"
"If we can leave cgroups to a better tool like LXC, that might be preferable for me but I'm not altogether opposed to them. My interest is having something that is both reliable and unintrusive. Maybe uselessd or openrc like you suggest can fit the criteria."

The emphasis on neutrality of proposed solution w/r to type of sys init
or service should not be overlooked !
Why is it then that this solution is not being implemented by the major distros with the same zeal (but without false pretenses) as in case of systemd ?

This whole debate saddens me

Posted Dec 3, 2014 18:03 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link]

> How about an alternative to what systemd proposed for managaement of cgroups (that is, a systemd, pid=1 dependent solution). How about systemd learning to live and cooperate in an ecosystem that is based on UNIX philosophy ?
I'm extremely worried about cgroups interoperability. There was a plan for systemd to own ALL of the cgroups and even forbid their modifications by other processes on the kernel level.

However, it seems that somebody had repeatedly beaten kernel cgroups maintainers with a cluebat. So it'll be possible to carve out a subtree out of the cgroups tree and manage it with any tool you want. Even perhaps namespace it for a custom container.

> The monitoring process need only handle the SIGCLD signal. Not only is this very easy to do, but it doesn't need any special permissions or non-standard configurations either.
No, it's not. SIGCHLD is woefully inadequate for process confinement. Only the _parent_ receives it.

For example, suppose that BIND11 launches a helper program 'zone_from_mongodb'. This program (in error!) launches a mongodb instance in the background. Mongodb does the regular daemon song-and-dance and reparents itself to the PID1.

But here's the catch - PID1 has no way to know that this mongodb process actually belongs to BIND11! So there'll be no way to terminate BIND11 cleanly - we'll leave a mongodb instance running in background.

So no, SIGCHLD is not nearly enough.

This whole debate saddens me

Posted Dec 3, 2014 18:13 UTC (Wed) by anselm (subscriber, #2796) [Link]

The emphasis on neutrality of proposed solution w/r to type of sys init or service should not be overlooked ! Why is it then that this solution is not being implemented by the major distros with the same zeal (but without false pretenses) as in case of systemd ?

Perhaps because doing it as part of PID 1 actually makes technical sense? It simplifies the implementation considerably, and a simpler implementation is usually a more robust implementation. Having a separate cgroup management process would lead to all sorts of nasty chicken-and-egg problems and/or duplication of functionality.

In addition, “the major distros” seem to be happy with systemd, which provides cgroups management for free, so there is little incentive to implement something else which is technically inferior, simply for the sake of “neutrality”. No major distribution is “neutral” with respect to things like the C runtime library or operating system kernel, but nobody seems to be bothered by that.

Finally, we're all looking forward to evaluating the alternative implementation of cgroups management that Devuan will hopefully provide in due course. If it is actually superior in practice to systemd's approach, then so much the better for all of us – but the Devuan people will need to build, test, integrate, and document it first. Words are cheap.

This whole debate saddens me

Posted Dec 3, 2014 20:43 UTC (Wed) by ms_43 (subscriber, #99293) [Link]

There was a comment in this very discussion by somebody who actually has relevant experience that explains why separating service management (and croup management is a core part of service management nowadays if you want to keep up with the competition in terms of provided reliability) into a process different from init has negligible practical benefit:

https://lwn.net/Articles/623527/

And the first comment you linked to provides a very good rationale for why service management and cgroup management should not be separated into different processes.

Why then would one want to run CGManager on top of systemd? It appears to be designed to run on systems that don't have systemd.

Btw if these cgroup namespace patches are going to be merged, that would simplify container delegation and i wonder if CGManager would become mostly obsolete.
https://lkml.org/lkml/2014/10/13/464