User: Password:
Subscribe / Log in / New account



Posted Jun 22, 2013 19:04 UTC (Sat) by ovitters (subscriber, #27950)
In reply to: Changes coming for systemd and control groups by zblaxell
Parent article: Changes coming for systemd and control groups

"except to implement evil"

You can interact with cgroup usage with systemd just fine. There is an wiki page describing this. Now the kernel is changing the API, systemd is following.

If the current API or the new API is not good enough, do the reasonable thing and reach out. Kernel people reached out to systemd. The systemd people reached out to figure out who is using cgroups.

Obviously you can just complain on the sidelines mumbling "evil", but documented actions by kernel and systemd doesn't reflect any evil doing.

Further, cgroup controllers are optional in systemd currently.

(Log in to post comments)


Posted Jun 22, 2013 23:50 UTC (Sat) by zblaxell (subscriber, #26385) [Link]

I have seen no sign that systemd maintainers believe the default data-losing behavior is dangerous or incorrect. Other users discussed these issues with the systemd maintainers on mailing lists or web fora in the past, and the bugs haven't been fixed yet. Will it be different if the issue is raised again? If so, how many times must issues be raised before they are fixed in this project?

Systemd is replacing simpler programs that have had 20 years of debugging attention paid to them, so obviously systemd will have plenty of bugs by comparison. Bugs I can cope with, but when the bugs are considered features by upstream I doubt there is much I can usefully contribute. I'll help Debian maintain a fork with sensible defaults if they ever adopt systemd, but I have no hope for upstream.


Posted Jun 23, 2013 4:42 UTC (Sun) by raven667 (subscriber, #5198) [Link]

It's hard to read through passive voice writing style but I'll bite, what in the world is the behaviour that you find so objectionable in systemd? You've written at least 500 words on it but I don't have a clue what you are talking about.


Posted Jun 23, 2013 8:15 UTC (Sun) by rahulsundaram (subscriber, #21946) [Link]

Oh, the drama. All you really want is the ability to tweak a setting and you will likely get that soon.


Posted Jun 23, 2013 15:43 UTC (Sun) by mathstuf (subscriber, #69389) [Link]

> I'll help Debian maintain a fork with sensible defaults if they ever adopt systemd, but I have no hope for upstream.

Please don't. One of the goals of systemd was to help standardize another layer of Linux. By doing the above, you'd only make a Debianism and make things still need distro checks for behavior.


Posted Jun 26, 2013 13:04 UTC (Wed) by hummassa (subscriber, #307) [Link]

Debian is not only Linux.

There are Debians with FreeBSD and NetBSD kernels, Solaris, and even Hurd. Systemd is (as it should be) available as an OPTION for Debian, but it should not be the default until it works at least as well as sysvinit in the other platforms.


Posted Jun 26, 2013 13:10 UTC (Wed) by micka (subscriber, #38720) [Link]

Is the default init system necessarily the same on all kernels ? I'm sure there are far more differences.

And if those other kernels are a technical obstacle to some progress, maybe the alternate kernel subproject should be asked to fix the problem themselves ?


Posted Jul 3, 2013 13:55 UTC (Wed) by zblaxell (subscriber, #26385) [Link]

It wouldn't be the first time someone tried to import some insane bug from some other community to Debian in the name of cross-distro consistency. I can't see any reason why I wouldn't work to push it back out again just like others before.

I realize some people disagree with me on this point. Several of them have posted here, repeating the assertion that they are not wrong after I just finished pointing out why they are. ;) Forks happen if your code's behavior as distributed is insane. This is one reason why we have different distributions.

I would likely only advocate a change to the default behavior, since the feature does have sane special cases and there seems to be commitment from upstream to maintain both behavior modes (although if it has to be configured in hundreds of separate places then a new global configuration point might still be preferable).

Packages that explicitly depend on having their processes killed under a possibly unconstrained list of scenarios defined by strangers from the future can always explicitly request that in their systemd configuration glue to ensure consistent cross-distribution behavior. All other packages will be much happier (and safer!) if left alone.

Copyright © 2018, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds