On Wed, 04.02.15 22:01, Lennart Poettering (lenn...@poettering.net) wrote: > On Wed, 04.02.15 15:06, Martin Pitt (martin.p...@ubuntu.com) wrote: > > > Hey, > > > > Lennart Poettering [2015-02-04 13:42 +0100]: > > > 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. > > > > > > With this change you alter that behaviour. Is that really desired? > > > > Since it's rather confusing what happens in this case, we made > > systemctl sync the status to update-rc.d (the chkconfig equivalent in > > Debian) on enable/disable: > > > > > > http://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/systemctl-don-t-skip-native-units-when-enabling-disa.patch > > > > That of course doesn't change the behaviour with manual rc?.d/ symlinks. > > > > But if you have a native unit, I think it's rather unexpected if you > > disable it with systemctl, enable it in sysv, but still get it > > started. > > I'd claim the opposite. Let's say you have foobar.rpm installed in one > version that only carried a sysvinit script. Now you upgrade it to a > version that has a service file. The fact that it was enabled > should not change... Hence, if it is enabled via sysv or via units > doesn't matter really right now...
Anyway, not too convinced that this is really the better option, but not too opposed either. Hence I am OK if something like this goes in. That said, please make sure to share the code from src/share/install.c for this, do not introduce a new search logic for unit files. Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
