Bug#727708: systemd as cgroup writer
Hi Andreas, Le samedi 21 décembre 2013 à 08:48 +0100, Andreas Barth a écrit : 1. Does systemd (or a part of the systemd project) need to be the single cgroup writer and if so, why? It does not… so far. The only thing currently required is for cgroups consumers to adhere to the shared guidelines¹ different projects agreed upon. As of today, there is no impact for us. What is changing is that the kernel cgroups developers want to fix the current mess cgroupfs has become². The identified solution is to only allow one cgroupfs hierarchy to be mounted and to let it be managed only by one process. The future kernel API has not been completely stabilized yet, but that much is clear. If you use systemd, this cgroups arbitrator has to lie in systemd itself. This is because systemd already starts all services as part of cgroups from PID 1. Otherwise, you can use another arbitrator such as cgmanager. Both have chosen the approach to provide the cgroups functionality as a D-Bus API to cgroups consumers (which makes a lot of sense). As I understand the transition plan, it goes this way: 1. Migrate cgroups consumers to a D-Bus API instead of using cgroupfs directly. 2. Stabilize the new kernel API and start providing it in the kernel. 3. On a switch day, the cgroups arbitrator starts mounting cgroupfs with the new API. Consumers still accessing the old API stop working. 4. The old kernel API is deprecated and eventually removed in the distant future. Systemd developers are getting ready to part 3 by working closely with the kernel cgroups developers. It is not clear to me whether cgmanager will be able to do the same: from my discussions with more knowledgeable people, it is merely exposing the current cgroups API in D-Bus calls. This approach cannot work transparently when the API changes. Therefore, we might only have one available cgroups arbitrator in the end: systemd. ① http://www.freedesktop.org/wiki/Software/systemd/PaxControlGroups/ ② http://www.linuxfoundation.org/news-media/blogs/browse/2013/08/all-about-linux-kernel-cgroup%E2%80%99s-redesign 2. What problems do arise from there for other parts of the linux ecosystem? These other parts have to migrate to a D-Bus-based interface. The problem is that systemd and cgmanager developers have not been able so far to agree on a common API. The consequences for those cgroups-consuming services are easy to infer. * Some services will only support systemd. * Some will use more complex code in order to support both. * Some will wait until a “standard” emerges and will not work towards the transition. With the systemd API being already available³ and part of the stability promise⁴, the only way this can happen is for cgmanager to start providing a systemd-compatible API, which in turn is unlikely since these are just extensions to the base API controlling systemd itself. Expect Red Hat, Samsung or Intel to provide patches if one of their products includes a relevant package. I think this is already the case for libvirt and LXC. ③ http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface/ ④ http://www.freedesktop.org/wiki/Software/systemd/InterfacePortabilityAndStabilityChart/ Cheers, -- .''`. Josselin Mouette : :' : `. `' `- -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387628136.24917.40.camel@tomoyo
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Russ Allbery Ian Jackson ijack...@chiark.greenend.org.uk writes: Russ Allbery writes: I'd like to see both of them support systemd's method, since it's extensible and provides more general functionality. I think the benefit of support for SIGSTOP is marginal; adding sd_notify calls is not that much harder and doesn't have the conceptual weirdness of stopping the daemon to notify the init system that it's running. I strongly disagreee. As the upstream author of a daemon I'm - not willing to add a library dependency for this - not willing to write a 50-100 lines of tiresome socket code for this - not willing to copy the library file into my source tree so the result is that userv upstream won't support systemd's readiness protocol. Yes, we completely disagree. Among other things, that's about the smallest and least-impactful library dependency I can imagine. sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87txe2xt2j@xoog.err.no
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I agree with Ian's dislike of this approach. We try to avoid embedded code copies, and I'm not sure why this would be an exception. Yes, the code is fairly simple and hopefully doesn't contain (for example) security vulnerabilities, but it's possible to find bugs in just about anything. Updating numerous copies of that code is not appealing. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/8738lmw3m3@windlord.stanford.edu
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
]] Russ Allbery Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I agree with Ian's dislike of this approach. We try to avoid embedded code copies, and I'm not sure why this would be an exception. Yes, the code is fairly simple and hopefully doesn't contain (for example) security vulnerabilities, but it's possible to find bugs in just about anything. Sure. There's a tradeoff as always. I wanted to point out that embedding it is intentionally easy. -- Tollef Fog Heen UNIX is user friendly, it's just picky about who its friends are -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/m2vbyihqq8@rahvafeir.err.no
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
On Sat, 2013-12-21 at 08:49 -0800, Russ Allbery wrote: Tollef Fog Heen tfh...@err.no writes: sd-daemon.c is also intentionally designed to not have dependencies on the rest of the systemd source and to be portable to non-linux architectures too (but basically just stubs then) just so people can put the file in their source and not have to fiddle with checking for libraries and such if they find that tedious. I agree with Ian's dislike of this approach. We try to avoid embedded code copies, and I'm not sure why this would be an exception. Yes, the code is fairly simple and hopefully doesn't contain (for example) security vulnerabilities, but it's possible to find bugs in just about anything. Updating numerous copies of that code is not appealing. I don't see why that should be considered a particularly significant downside though. Copies are usually worse than shared code, but not really worse than everything having a custom implementation. At least implementing sd_notify() support with a code copy should be considered a significant improvement over a daemon that always runs custom double-forking code. BTW it's worth noting that in the typical daemon case where readiness means the listening socket is ready to accept requests, the right way to convert the daemon to a new API is to use socket activation, which removes the need for separate start-up completion notification. Thus the need to use sd_notify() for this purpose should be the exception rather than the rule. This means that daemons which would use libsystemd-daemon for startup notification and nothing else (and would thus be potential candidates to abuse SIGSTOP) should be rare. -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1387662984.3938.143.camel@glyph.nonexistent.invalid
Bug#727708: upstart proposed policy in Debian [and 1 more messages]
Uoti Urpala uoti.urp...@pp1.inet.fi writes: BTW it's worth noting that in the typical daemon case where readiness means the listening socket is ready to accept requests, the right way to convert the daemon to a new API is to use socket activation, which removes the need for separate start-up completion notification. Thus the need to use sd_notify() for this purpose should be the exception rather than the rule. This means that daemons which would use libsystemd-daemon for startup notification and nothing else (and would thus be potential candidates to abuse SIGSTOP) should be rare. Good point. Anything that's using socket activation probably doesn't really need additional synchronization. -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/87ppopua6g@windlord.stanford.edu
