Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
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
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
Jóhann B. Guðmundsson [2015-02-04 22:36 +]: I expect Debian to do the same sane thing as everyone else did back in the day and strike out that components will be allowed to migrate to units [...] Then next thing the Debian community will realize is that once maintainers have made the switch to use units they will have to stick the legacy sysv initscript in a separated sub component which will depend on a virtual provide for all the other init systems ( that is if the maintainers want to support those et all ). For the record: For the time being, Debian doesn't migrate from sysv to systemd; it keeps all sysv init scripts as it also still needs to work with sysvinit, so it keeps units and sysv scripts in sync. (Just stating the situation; I don't want to discuss the why really, that was long and painful enough :-) Just describing the status quo). Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
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.
This is particularly relevant if you have lots of init.d scripts, like
we have on Debian. Other than that it's not a behaviour change AFAICS.
I cleaned it up a bit and added a test case.
One thing I wonder about is whether native_unit_exists() should
perhaps be moved into src/shared/? It might be useful for other stuff.
Thanks,
Martin
--
Martin Pitt| http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)
From ae066ed5d5b7312eb8debc30970f6e56919fa7c7 Mon Sep 17 00:00:00 2001
From: Jon Severinsson j...@severinsson.net
Date: Wed, 2 Jul 2014 22:00:00 +0200
Subject: [PATCH] sysv-generator: Skip init scripts for existing native
services
There's no need to do all the parsing and creation of service files if we
already have a native systemd unit for the processed SysV init script.
---
src/sysv-generator/sysv-generator.c | 30 +-
test/sysv-generator-test.py | 12
2 files changed, 41 insertions(+), 1 deletion(-)
diff --git a/src/sysv-generator/sysv-generator.c b/src/sysv-generator/sysv-generator.c
index 673f04d..3052326 100644
--- a/src/sysv-generator/sysv-generator.c
+++ b/src/sysv-generator/sysv-generator.c
@@ -723,6 +723,25 @@ static int fix_order(SysvStub *s, Hashmap *all_services) {
return 0;
}
+static int native_unit_exists(LookupPaths lp, char *name) {
+char **p;
+
+STRV_FOREACH(p, lp.unit_path) {
+struct stat st;
+_cleanup_free_ char *path = NULL;
+
+path = strjoin(*p, /, name, NULL);
+if (!path)
+return -ENOMEM;
+
+if (lstat(path, st) 0)
+continue;
+
+return 1;
+}
+return 0;
+}
+
static int enumerate_sysv(LookupPaths lp, Hashmap *all_services) {
char **path;
@@ -768,6 +787,14 @@ static int enumerate_sysv(LookupPaths lp, Hashmap *all_services) {
if (!fpath)
return log_oom();
+r = native_unit_exists(lp, name);
+if (r 0)
+return log_oom();
+if (r 0) {
+log_debug(Native unit for %s already exists, skipping, *path);
+continue;
+}
+
service = new0(SysvStub, 1);
if (!service)
return log_oom();
@@ -852,7 +879,8 @@ static int set_dependencies_from_rcnd(LookupPaths lp, Hashmap *all_services) {
service = hashmap_get(all_services, name);
if (!service){
-log_warning(Could not find init script for %s, name);
+log_debug(Ignoring %s symlink in %s, not generating %s.,
+ de-d_name, rcnd_table[i].path, name);
continue;
}
diff --git a/test/sysv-generator-test.py b/test/sysv-generator-test.py
index 5098519..89df72a 100644
--- a/test/sysv-generator-test.py
+++ b/test/sysv-generator-test.py
@@ -367,6 +367,18 @@ class SysvGeneratorTest(unittest.TestCase):
self.assert_enabled('foo.bak.service', [])
self.assert_enabled('foo.old.service', [])
+def test_existing_native_unit(self):
+'''existing native unit'''
+
+with open(os.path.join(self.unit_dir, 'foo.service'), 'w') as f:
+f.write('[Unit]\n')
+
+self.add_sysv('foo.sh', {'Provides': 'foo bar'}, enable=True)
+err, results = self.run_generator()
+self.assertEqual(list(results), [])
+# no enablement or alias links
+self.assertEqual(os.listdir(self.out_dir), [])
+
if __name__ == '__main__':
unittest.main(testRunner=unittest.TextTestRunner(stream=sys.stdout, verbosity=2))
--
2.1.4
signature.asc
Description: Digital signature
___
systemd-devel mailing list
systemd-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
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? 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. Take an example, where a single sysv init script foo was split up into multipe systemd unit, like foo.service, foo.socket and bar.service. Isn't it inconsistent, if now, only foo.service was enabled? -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 2015-02-04 at 15:06 +0100, Martin Pitt wrote: 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? So in that regard it would be an intended behaviour change indeed. But either way this is a corner case for sure. I just wouldn't like to carry this patch forever as it's relatively unimportant. Maybe Jon can chime in about his intentions with this? Isn't this change also relevant to the creation of .wants symlinks, and avoiding generating .wants links from the wrong targets? As in, the case where you override a rcS.d sysvinit service with a multi-user.target systemd unit (or other less common runlevel combinations for distros that don't have any rcS.d level sysv any more). You want to avoid generating a .wants symlink from an early boot target, even if a generated unit file itself would be shadowed by the native unit. ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 04.02.15 21:26, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: On Wed, 2015-02-04 at 15:06 +0100, Martin Pitt wrote: 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? So in that regard it would be an intended behaviour change indeed. But either way this is a corner case for sure. I just wouldn't like to carry this patch forever as it's relatively unimportant. Maybe Jon can chime in about his intentions with this? Isn't this change also relevant to the creation of .wants symlinks, and avoiding generating .wants links from the wrong targets? As in, the case where you override a rcS.d sysvinit service with a multi-user.target systemd unit (or other less common runlevel combinations for distros that don't have any rcS.d level sysv any more). You want to avoid generating a .wants symlink from an early boot target, even if a generated unit file itself would be shadowed by the native unit. systemd does not support sysv scripts for early-boot targets anymore. This has been removed long ago. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 2015-02-04 at 22:02 +0100, Lennart Poettering wrote: On Wed, 04.02.15 21:26, Uoti Urpala (uoti.urp...@pp1.inet.fi) wrote: Isn't this change also relevant to the creation of .wants symlinks, and avoiding generating .wants links from the wrong targets? As in, the case where you override a rcS.d sysvinit service with a multi-user.target systemd unit (or other less common runlevel combinations for distros that don't have any rcS.d level sysv any more). You want to avoid generating a .wants symlink from an early boot target, even if a generated unit file itself would be shadowed by the native unit. systemd does not support sysv scripts for early-boot targets anymore. This has been removed long ago. Yes, but Debian patches rcS.d support back in because they still haven't managed to create native units for every package. And as the comment in parenthesis says, the same issue still exists in principle on other distros with other runlevels (though is less common and important than on Debian). ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
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... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
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
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On 02/04/2015 09:20 PM, Lennart Poettering wrote: 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. Could not a downstream use a component based preset file hack to overcome this? + this is extremely limited to Debian and Debian based distribution these days and since you don't seem to recall what happened in Fedora during the transaction period where users had to manually enable services ( again ) after the change from the legacy script to unit in components during upgrades ( that chkconfig hack FPC came up with, approved, implemented and had everybody follow to handle upgrades did not work, like many other decision FPC has come up with and made in their infinite collective wisdom ). I expect Debian to do the same sane thing as everyone else did back in the day and strike out that components will be allowed to migrate to units after beta ( or no later then just before the final release ), so end users running the latest stable version of Debian that started with an installed sys script wont suddenly find themselves in midst of it's release cycle switching to units. Those doing release upgrades can as always expect breakage and or manual intervention of some sort so manually enable stuff again is not to overcoming and is not a usecase to consider. Then next thing the Debian community will realize is that once maintainers have made the switch to use units they will have to stick the legacy sysv initscript in a separated sub component which will depend on a virtual provide for all the other init systems ( that is if the maintainers want to support those et all ). The Debian maintainers and or it's leader can already cut corners in exhausting decision making and policy handling and just look at how all the other distribution ( fedora,opensuse,mageia etc ) handled this and have handle this and follow it ( as oppose to re-invent the wheel ) and keep all workarounds and hacks to support that transformation and multiple init system downstream ( like everyone else had to do ). JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
On Wed, 04.02.15 10:08, Martin Pitt (martin.p...@ubuntu.com) wrote: 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. With this change you alter that behaviour. Is that really desired? (Not saying it wasn't desired, just pointing out the difference, and asking for some consideration of this issue?) This is particularly relevant if you have lots of init.d scripts, like we have on Debian. Other than that it's not a behaviour change AFAICS. I cleaned it up a bit and added a test case. One thing I wonder about is whether native_unit_exists() should perhaps be moved into src/shared/? It might be useful for other stuff. We have similar code in src/shared/install.c already, this should really be unified... I must say I kinda like the fact though that the sysv generator knows nothing about native units so far... Anyway, not totally opposed, but I'd like to hear some analysis first why this change in behaviour does not matter. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH] sysv-generator: Skip init scripts for existing native services
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. It seems to me that systemctl disable should win here -- after all, that's closer to the running systemd than the rc.d links. So in that regard it would be an intended behaviour change indeed. But either way this is a corner case for sure. I just wouldn't like to carry this patch forever as it's relatively unimportant. Maybe Jon can chime in about his intentions with this? Thanks, Martin -- Martin Pitt| http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
