Michael Biebl wrote on 04/02/15 19:59: > 2015-02-04 13:42 GMT+01:00 Lennart Poettering <lenn...@poettering.net>: >>> Hello all, >>> >>> a little while ago, Jon Severinsson wrote a sysv generator >>> optimization to not go through all the parsing of init.d scripts and >>> creation of units if there already is a native unit for that name. As >>> they are put into generator.late they would be ignored anyway. >> >> Well, but their enablement status so far is not ignored. i.e. if you >> drop in a unit file, as well as a sysv script, and the latter is >> enabled, but the former not, then systemd currently reads that so that >> the sysv one is overriden by the native one, and the native one is >> considered enabled. > > I actually find it confusing, if the enablement state of the sysv init > script overrides the native one. > What were the reasons to do it this way?
Wow! I have to say, I never knew this. Is it really this way just now? I always thought that when a native unit existed, *anything* to do with sysv was basically ignored - the script itself *and* it's enablement states. That's certainly the assumption I've made in the past! When we upgrade a package to include a native unit, we simply have a one time migration of the enablement state from sysv to native (with a tracking file to store the "we've migrated enablement state). After that, we don't care about whether or not a user tries to enable things or not in sysvinit (and we don't care about maintaining sysv support as there is no going back in our case). Ultimately it doesn't matter too much as chkconfig will actually redirect to systemctl anyway, so users will have a hard time using it to actually create sysvinit symlinks. We only really have to worry about manually created links going forward. We also typically drop the sysvinit script these days, (i.e. both tend not exist in a package except in the case of packager laziness). Still don't like the idea that an enabled sysvinit package, upgrade to one that has a native unit and a legacy sysvinit script (due to packager laziness in our case) which the sysadmin later disables, would end up effectively being enabled via the still present sysvinit symlinks. > The following behaviour is imho more consistent: > a/ only a sysv init script available: use sysv init script and its > enablement state > b/ only a native service file: use native service file and its enablement > state > c/ both sysv init script and native service file available: use native > service file and its enablement state. Totally agree, and as I said above, this was always my assumption on how things worked!! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
