[systemd-devel] [PATCH 1/2] systemctl: Don't skip native units when enabling/disabling SysV init.d scripts

[Lennart Poettering]

On Wed, 27.05.15 15:26, Martin Pitt (martin.pitt at 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