On 10/21/2014 at 10:35 AM, Matthias Urlichs wrote: > Hi, > > The Wanderer: > >>> Can you give an example of people doing that in case of systemd? >>> Because so far, everything I heard was similar to GNOME, where: >>> • systemd provided a feature. >> >> This is the problem. The init system should not be providing >> "features" which other software might, post-boot and pre-shutdown, >> want to make use of. > > Define "post-boot". What about socket activation? Or starting up my > database when the iSCSI link to the storage comes up, instead of > *whenever*? Or cleanly restarting my Apache heap-of-processes? None of those things are done exclusively at boot / shutdown time, so they should not be done by the init system. If they are done at all, they should be done by something which can run and do them under any init system. > Please explain why it should *not* provide these "features". Why > should every daemon (or its startup script) re-implement the same > code to put itself in the background, change UIDs, resource-limit > and security-enhance (private /tmp) itself,when the same thing can > be implemented once, so that I as a sysadmin (or my puppet script) > don't have to learn ten separate ways of configuring that? I never said every daemon, et cetera, should reimplement those things. They shouldn't. Those things should be implemented centrally, in something which can work irrespective of the current init system. (Barring possibly a hypothetical init system which actively tries to prevent it from working.) > There are a bunch of things systemd can do which sys5rc can't do. Why > is it a "design flaw" to provide these in the way that's easiest to > implement, and therefore (presumably) least buggy? Because, since there is only one slot for PID 1 per system, having something depend on a feature that is provided by PID 1 breaks choice. (This is an overly simplistic answer, but I've spent half an hour writing possible more-detailed responses to this so far, and none of them seem both accurate and unlikely to be misconstrued.) Note that I (think I) would have no objection to providing such features both in PID 1 (for its own use) and in an init-system-independent external process, with PID 1 providing them for use by other things only if and as no external provider is available. (In fact, if I'm understanding things correctly, systemd itself used to do it that way with cgroups management until the kernel upstream decided that having multiple cgroups managers running at once was broken design and would not be supported.) Something vaguely like that is what seems to be being worked towards (with some current success) by the systemd-shim project, which is something of a kludge, and will inevitably be chasing whatever interface changes systemd upstream chooses to make. It would be better design to decide to provide that separate implementation as part of the main project itself (in terms of maintenance, not necessarily of integration), rather than as a third-party backfill. >> The decision to incorporate such features into systemd is IMO the >> design flaw which leads to the problems to which people object. >> That decision was made by the systemd developers > > for a couple of reasonably good reasons. You might want to debate > the validity of these reasons and the difficulty of doing it some > other way, assuming that there's a tangible benefit of doing it > another way in the first place. Having ten processes responsible for > bits&pieces of what systemd-as-PID1 does instead of one isn't a > benefit -- not if all you gain by that is nine additional processes. That isn't all you gain by it; you also gain the benefit of being able to use these features no matter which init system you're running. Which in turn helps avoid lock-in, and enable easier testing of (or migration to) alternatives, and prevent user surprise, and so forth. > "It's a big monolithic thing, and big monolithic things are bad and > evil and non-Unix-y, so there!!1!" is not a valid argument. And it's not an argument I'm making, at least not at present. I'm not aware of what those reasons are, unless you're referring to the points referenced in the systemd position statement which Josselin quoted. My response to that is that "do it this way" vs. "do it some other way" ignores the possibility of "don't do it at all", which may be the correct choice in some cases. -- The Wanderer The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man. -- George Bernard Shaw
Attachment:
signature.asc
Description: OpenPGP digital signature