Another daemon for managing control groups [LWN.net]

Another daemon for managing control groups

Posted Jan 3, 2014 19:15 UTC (Fri) by dlang (guest, #313)
In reply to: Another daemon for managing control groups by raven667
Parent article: Another daemon for managing control groups

even the systemd developers admit that there are linux systems out there that should not run systemd (embedded type systems for example), but those systems may still want to use some of the features that systemd is trying to take over and kill off the competition in.

how would you use cgroups on a wireless access point where you don't want to run systemd but still want to limit some set of processes?

to post comments

Another daemon for managing control groups

Posted Jan 3, 2014 20:03 UTC (Fri) by raven667 (guest, #5198) [Link] (6 responses)

It's a tautology really, if you don't want to run systemd for whatever reason, then don't run systemd.

> ... features that systemd is trying to take over and kill off the competition in.

I'm not sure what "take over" means in this context if you aren't running systemd on a system because you don't want to than what systemd does is not of relevance to you except as an example. The only way they are "killing the competition" is by making a high-quality, feature-rich offering which people want to use, they are out-competing the competition. I hope we can all agree that they shouldn't hobble the implementation and make it less useful just to make the competition look better...

> how would you use cgroups on a wireless access point where you don't want to run systemd but still want to limit some set of processes?

You do whatever you want to do, within the confines of the kernel interface, which in the future will want a single-writer (although compatibility with the existing interface will be maintained for some time as I understand it). So you can make your own cgroup manager daemon, being advised that there are fundamental problems with restarts, race conditions, etc. and that this can only manage a subset of processes (ones that it starts), or you write your custom manager into pid 1 either from scratch or patching one of the existing inits to have the logic you want.

There are probably going to be a handful of small cgroup managers that you can start from which are dedicated to specific tasks like HPC or Google, although if systemd incorporates whatever configuration toggles these workloads need then many will probably just use that rather than re-implement something themselves, but there is always someone out there who wants to do it themselves and is distrustful of any third party code 8-)

Really, how is this different from today where if you want to use this kernel feature you have to have your software talk to the kernel and twiddle it. How is it different than iproute2 or iptables?

Another daemon for managing control groups

Posted Jan 3, 2014 21:44 UTC (Fri) by dlang (guest, #313) [Link] (4 responses)

> The only way they are "killing the competition" is by making a high-quality, feature-rich offering which people want to use, they are out-competing the competition.

not quite, they also campaign to get the competition removed from the distro (or at least the default installation of the distro), rsyslog vs journald in Fedora is an example of this in practice.

Another daemon for managing control groups

Posted Jan 3, 2014 21:48 UTC (Fri) by mchapman (subscriber, #66589) [Link] (3 responses)

> they also campaign to get the competition removed from the distro (or at least the default installation of the distro)

Is that so surprising? Clearly they think they have a better solution. They *should* be campaigning for it, if that's what they really think.

I'm sure distro maintainers are smart enough to judge the various options available on their merits.

Another daemon for managing control groups

Posted Jan 3, 2014 21:54 UTC (Fri) by dlang (guest, #313) [Link] (2 responses)

they can campaign to have their system added, but what's the justification for removing the other option, especially when it can co-exist with theirs and provide capabilities that they don't offer?

Another daemon for managing control groups

Posted Jan 3, 2014 21:59 UTC (Fri) by mchapman (subscriber, #66589) [Link]

> they can campaign to have their system added, but what's the justification for removing the other option, especially when it can co-exist with theirs and provide capabilities that they don't offer?

For Rsyslog in Fedora specifically?

According to the Change page [1]:

1. Less disk and runtime footprint
2. Fewer packages in the default install
3. Faster booting

Now, you can argue whether those are *sufficient* justification for the removal of syslog from the default install. I'm sure people did.

At the end of the day, though, the vote was in that this Change should go ahead.

[1] https://fedoraproject.org/wiki/Changes/NoDefaultSyslog

Another daemon for managing control groups

Posted Jan 3, 2014 22:02 UTC (Fri) by raven667 (guest, #5198) [Link]

But they haven't removed rsyslog, and in fact rsyslog is required if you want to do central logging using syslog, systemd and the journal will pass through log messages to it. What they aren't doing is installing both logging systems by default. There is also no default sendmail in Fedora either.

Other distros make different decisions but rsyslog integration is still an important part of the journal, heck its even an important part of rsyslog which added support for the journal on-disk data format as I recall.

Another daemon for managing control groups

Posted Jan 3, 2014 21:46 UTC (Fri) by dlang (guest, #313) [Link]

> Really, how is this different from today where if you want to use this kernel feature you have to have your software talk to the kernel and twiddle it. How is it different than iproute2 or iptables?

iproute2 and iptables are happy to sit on a system and only be used for the parts that you want them to be used for. They don't try really hard to force you to do things a specific way and push you to replace a bunch of other tools if you use them.