[systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services

[Colin Guthrie]

Michael Biebl wrote on 04/02/15 19:59:
> 2015-02-04 13:42 GMT+01:00 Lennart Poettering <lennart at 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/