[systemd-devel] systemctl preset and chkconfig

[Lennart Poettering]

On Fri, 22.08.14 15:51, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> Hi,
> 
> I recently changed my %post scripts in Mageia to use systemctl preset
> rather than systemctl enable to allow for policy-based overrides of
> "enable on install" behaviour.
> 
> Sadly, unlike enable, preset does not shell out to chkconfig, so passing
> a service name that's not got a native unit no longer gets enabled.
> 
> Now I can work around this in our %post scripts, but an alternative
> would be to teach preset about chkconfig and shell out to that if a
> native unit is not found.
> 
> I'm not overly bothered where I work around this and of course long term
> goal is not to ship any sysvinit scripts anyway. But before I work on a
> solution, would upstream be interested in preset supporting chkconfig?
> 
> If not, it's probably quicker and easier for me to do the work and
> maintain it in scripts rather than systemctl itself, hence why I figured
> I'd ask first.

Currently the compat support for chkconfig is nicely hidden in
systemctl on the client side, and doesn't spill into the backend code on
the server side. Forking off chkconfig from PID 1 sounds like something
I'd be very cool about...

Generally we have the rule of not extending compat features beyond what
they did in the implementation we try to be compatible with. In this
case this would probably mean that presets weren't available in
chkconfig, and hence they won't be available when chkconfig is invoked
via systemctl...

I am not entirely sure I get the usecase here. If you invoke this from
an RPM scriptlet, then you apparently make the package
systemd-aware. But if you do, then why not also write a systemd unit
file? I mean, it sounds weird doing one but not the other? What's the
rationale here?

Lennart

-- 
Lennart Poettering, Red Hat