Le Lun 20 juin 2011 12:41, Mathieu Bridon a écrit : > > On Mon, 2011-06-20 at 11:20 +0200, Reindl Harald wrote: >> this is NOT solveable they way systemd fires up sysv services > > It is, but it might be a too disruptive update to be allowed in a stable > release. Really, systemd's "pretty decent compatibility with sysv initscripts" is overrated. systemd sysV ordering depends on LSB sysV headers that where essentially *ignored* in Fedora. Most historical Fedora sysV services relied *only* on service number to get started in the right order. Even if they had some LSB stuff in, it was completely untested (just look at how the sysV services are labelled in systemd, clearly no one even checked the service descriptions before and that's *simpler* than getting deps right). Since systemd ignores those numbers as soon as there is something looking like an lsb dep in the service chain (that may have been put in as an experiment years before, or as a cut and pasted boilerplate the maintainer didn't care about), a lot of Fedora sysV scripts are *not* compatible with systemd unless rewritten in LSB dependency style. So what is the point of effectively rewriting existing sysV services in a new sysV dialect now (to rewrite them again next release as native systemd units) instead or rewriting them directly as systemd services? In both cases there is a high risk of regressions as dependency logic was not tested before. Except that systemd works better with native units, so I'm far from sure the less risky path is to try to "fix" sysV services so they semi-work. -- Nicolas Mailhot -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
