Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On 05/27/2015 04:00 PM, Lennart Poettering wrote: On Wed, 27.05.15 13:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 05/27/2015 01:07 PM, Martin Pitt wrote: Hello, as discussed in the get some distro patches upstream thread, this is the generalization for supporting different chkconfig/update-rc.d/whatnot distro implementations of enabling init.d scripts, as per LSB specification. Is this not something that downstream should be carrying tailored to what init implementation what was used in the past and or is shipped in the present, ( Debian for example ships/supports multiple init systems ) and the support for this dropped upstream? Well, I think it's too early for that. 3rd party software tends to be written for LSB. Also, Debian/Ubuntu only very recently switched to sytemd. Out of fairness we owe them to support the old stuff natively for a while, the same way we benefitted from that during the fedora transition. Last time I checked Debian shipped the most initscripts of the distributions roughly half more then we do in Fedora ( ca 1200 components ). Now if we put aside Debians support for multiple initsystem which makes it more likely that they prefer using generators instead of actually migrate components and we subtract the collaborated migration effort done by us systemd integrators that resided in distributions community that we did together for what past 4 or five years, it will leave ca 600 components for Debian to migrate and they will do so in roughly the same time frame as we all did collectively I would expect. Add to that the long discussion, approval period in Debian's community before that work would actually start to happen, we are talking about supporting this for 5 - 7 years more ( unless something is done here , upstream to nudge it's completion sooner ). 3rd party software will not migrate until they have to that is a fact ( and distributions and upstream cannot wait for something they have absolutely no control over which is another fact ). Also, there are still ~100 sysv scripts in fedora too... I'm perfectly aware the status on unmigrated components along with other systemd integration and cleanup work has not progressed since I stopped leading and doing that in Fedora and now that has started to hinder other work ( as I had expected would happen ) but this is what some of your coworkers wanted and this is precisely what they got with the associated cost of their behavior and decision(s) which ultimately will cost Red Hat more in work,money and delays of it's upcoming RHEL release(s) There was an FESCo discussion dropping all the 100 - 150 components that had not been migrated in F23 with Adam Jackson valiantly assigning an task to himself and trying migrated what he could up to that point ( kudos to him for that. I have not seen that spirit in FESCo member since what FC5/6 ) I just dont think he realized how much amount of work that was nor how distracting it would become from his other work/upstream obligations not that I have checked but I expect that he has abandoned that work by now or it's progressing very very slowly. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On Wed, 27.05.15 15:07, Martin Pitt (martin.p...@ubuntu.com) wrote:
Hello,
as discussed in the get some distro patches upstream thread, this is
the generalization for supporting different
chkconfig/update-rc.d/whatnot distro implementations of enabling
init.d scripts, as per LSB specification.
I figure at some point we might want to drop the explicit
--enable-chkconfig support and instead provide a Fedora/RedHat
chckconfig wrapper in /usr/lib/lsb/{install,remove}_initd ? Then we
can get rid of the #ifdeffery and some code.
Such a wrapper should be added downstream in the Fedora initscripts
package I am sure... I'd like to fully remove native support for this
Fedora tool upstream. The fewer distro-specific hacks the better.
I tested this with enabling/disabling with only systemd unit and
only SysV unit, both with and with not having the LSB wrappers. If
there is both a script and a unit for the same name we need a second
patch, will post that separately as 2/2 as it's unrelated to this
change.
If we do this, then I'd like to go all the way right-away: strip
chkconfig support if we add support for the new hook.
if (!streq(verb, enable)
-!streq(verb, disable)
-!streq(verb, is-enabled))
+!streq(verb, disable)
+/* LSB has no way of checking the enablement status */
+#if defined(HAVE_CHKCONFIG)
+ !streq(verb, is-enabled)
+#endif
+)
return 0;
[...]
-log_info(%s is not a native service, redirecting to
/sbin/chkconfig., name);
-
+#if defined(HAVE_CHKCONFIG)
+argv[0] = /sbin/chkconfig;
if (!isempty(arg_root))
argv[c++] = q = strappend(--root=, arg_root);
@@ -5170,6 +5174,25 @@ static int enable_sysv_units(const char *verb, char
**args) {
argv[c++] =
streq(verb, enable) ? on :
streq(verb, disable) ? off : --level=5;
+
+#else
+if (!isempty(arg_root) !streq(arg_root, /)) {
+log_error(Can not %s SysV init script when a root
directory other than / is specified, verb);
+continue;
+}
Hmm, this makes me feel a bit uneasy about the LSB support... If
neither is-enabled nor --root= can covered by the LSB tool, I
wonder if we should use it at all... Also, as it appears the LSB tool
only takes a single script per invocation, which is also incompatible
with how we need it...
Maybe introducing a new tool for this that covers all options is the
better idea. Let's call it /usr/lib/systemd/systemd-sysv-install or
so, taking the --root= switch as before, plus enable, disable,
is-enabled plus one or more LSB init script names is the better
option... Distros implementing LSB can then direct this tool to the
LSB tools if they wish, and Fedora can translate this to chkconfig,
without losing any functionality...
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 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On Wed, 27.05.15 15:26, Martin Pitt (martin.p...@ubuntu.com) wrote:
Lennart Poettering [2015-05-27 15:18 +0200]:
If we do this, then I'd like to go all the way right-away: strip
chkconfig support if we add support for the new hook.
OK.
+if (!isempty(arg_root) !streq(arg_root, /)) {
+log_error(Can not %s SysV init script when a
root directory other than / is specified, verb);
+continue;
+}
Hmm, this makes me feel a bit uneasy about the LSB support... If
neither is-enabled nor --root= can covered by the LSB tool, I
wonder if we should use it at all...
You give it the full path, so we could also just invoke it with
path_join(arg_root, p).
That sounds wrong, as that might result in symlinks created in
/etc/rc.d rather that $(root)/etc/rc.d, if you follow what I
mean... Moreover, the symlinks might end up pointing to absolute paths
including the $root prefix, and that would even be worse...
It really matters to pass the root prefix as such to the tool instead
of simply prefixing it to the init script...
As for is-enabled, since that doesn't exist anywhere we could try and
call /usr/lib/lsb/initd_enabled.
We really shouldn't place this in the LSB namespace if we aren't LSB.
Also, as it appears the LSB tool only takes a single script per
invocation, which is also incompatible with how we need it...
I didn't see that being used anywhere in the systemd source, did I
miss anything? If so, you can always call stuff in a loop instead,
no?
Sure, but I think the hook should provide for this natively, instead
of us emulating things around it... But dunno, this certainly isn't a
major issue...
Maybe introducing a new tool for this that covers all options is the
better idea. Let's call it /usr/lib/systemd/systemd-sysv-install or
so, taking the --root= switch as before, plus enable, disable,
is-enabled plus one or more LSB init script names is the better
option... Distros implementing LSB can then direct this tool to the
LSB tools if they wish, and Fedora can translate this to chkconfig,
without losing any functionality...
I kinda like adhering to LSB, at least where it makes sense; obviously
we don't have a specification for is-enabled, so we have to make up
one (/usr/lib/lsb/initd_enabled), but for enable/disable it seems
quite fine?
Well, again, it covers neither --root=, nor is-enabled, and we
shouldn't pollute foreign namespaces like this.
I mean, you can try to get both the --root= and the is-enabled thing
into LSB proper, but that would take ages, of course... (is the LSB
process even still alive?)
Extending the LSB definitions one-sided and stepping into their
namespace is something we really should not do. There's no point in
having namespaces at all if we ignore them and step into them
anyway...
But if you still say you want /usr/lib/systemd/systemd-sysv-install
I'll implement it that way. I care more about getting some abstraction
than getting an LSB compatible one :-)
I think I would prefer that.
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 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On 05/27/2015 01:07 PM, Martin Pitt wrote: Hello, as discussed in the get some distro patches upstream thread, this is the generalization for supporting different chkconfig/update-rc.d/whatnot distro implementations of enabling init.d scripts, as per LSB specification. Is this not something that downstream should be carrying tailored to what init implementation what was used in the past and or is shipped in the present, ( Debian for example ships/supports multiple init systems ) and the support for this dropped upstream? In the end of the day we *want* the init scripted mess be migrated to native systemd units and the only way that will ever be done is if the support for it will be dropped upstream which forces distribution and vendors to either maintain the compatibility layer themselves and or actually go through the effort of migrating to native systemd units. I would think embedded and most distribution ( with the exception of Debian and Slackware ) should have migrated all their legacy sysv initscripts to native systemd initscripts by now. JBG ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On Wed, 27.05.15 15:30, Martin Pitt (martin.p...@ubuntu.com) wrote: Lennart Poettering [2015-05-27 15:18 +0200]: Maybe introducing a new tool for this that covers all options is the better idea. Let's call it /usr/lib/systemd/systemd-sysv-install or so, taking the --root= switch as before, plus enable, disable, is-enabled plus one or more LSB init script names is the better option... To reiterate, I'm really worried about multiple names. Not only does that needlessly complicate the implementation of the wrapper, it also seems like unnecessarily introducing ambiguity. What should is-enabled foo bar baz mean? any, all, first, error? Where do we need this? systemctl calls stuff one by one in a loop anyway? OK, sounds Ok to not do this then. 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 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
Lennart Poettering [2015-05-27 15:18 +0200]: Maybe introducing a new tool for this that covers all options is the better idea. Let's call it /usr/lib/systemd/systemd-sysv-install or so, taking the --root= switch as before, plus enable, disable, is-enabled plus one or more LSB init script names is the better option... To reiterate, I'm really worried about multiple names. Not only does that needlessly complicate the implementation of the wrapper, it also seems like unnecessarily introducing ambiguity. What should is-enabled foo bar baz mean? any, all, first, error? Where do we need this? systemctl calls stuff one by one in a loop anyway? 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
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
Lennart Poettering [2015-05-27 15:18 +0200]:
If we do this, then I'd like to go all the way right-away: strip
chkconfig support if we add support for the new hook.
OK.
+if (!isempty(arg_root) !streq(arg_root, /)) {
+log_error(Can not %s SysV init script when a root
directory other than / is specified, verb);
+continue;
+}
Hmm, this makes me feel a bit uneasy about the LSB support... If
neither is-enabled nor --root= can covered by the LSB tool, I
wonder if we should use it at all...
You give it the full path, so we could also just invoke it with
path_join(arg_root, p).
As for is-enabled, since that doesn't exist anywhere we could try and
call /usr/lib/lsb/initd_enabled.
Also, as it appears the LSB tool only takes a single script per
invocation, which is also incompatible with how we need it...
I didn't see that being used anywhere in the systemd source, did I
miss anything? If so, you can always call stuff in a loop instead, no?
Maybe introducing a new tool for this that covers all options is the
better idea. Let's call it /usr/lib/systemd/systemd-sysv-install or
so, taking the --root= switch as before, plus enable, disable,
is-enabled plus one or more LSB init script names is the better
option... Distros implementing LSB can then direct this tool to the
LSB tools if they wish, and Fedora can translate this to chkconfig,
without losing any functionality...
I kinda like adhering to LSB, at least where it makes sense; obviously
we don't have a specification for is-enabled, so we have to make up
one (/usr/lib/lsb/initd_enabled), but for enable/disable it seems
quite fine?
But if you still say you want /usr/lib/systemd/systemd-sysv-install
I'll implement it that way. I care more about getting some abstraction
than getting an LSB compatible one :-)
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
Re: [systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts
On Wed, 27.05.15 13:39, Jóhann B. Guðmundsson (johan...@gmail.com) wrote: On 05/27/2015 01:07 PM, Martin Pitt wrote: Hello, as discussed in the get some distro patches upstream thread, this is the generalization for supporting different chkconfig/update-rc.d/whatnot distro implementations of enabling init.d scripts, as per LSB specification. Is this not something that downstream should be carrying tailored to what init implementation what was used in the past and or is shipped in the present, ( Debian for example ships/supports multiple init systems ) and the support for this dropped upstream? Well, I think it's too early for that. 3rd party software tends to be written for LSB. Also, Debian/Ubuntu only very recently switched to sytemd. Out of fairness we owe them to support the old stuff natively for a while, the same way we benefitted from that during the fedora transition. Also, there are still ~100 sysv scripts in fedora too... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
