[systemd-devel] systemctl preset and chkconfig

[Lennart Poettering]

On Tue, 26.08.14 08:59, Colin Guthrie (gmane at colin.guthr.ie) wrote:

> >> 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...
> 
> I presume you missed a negative in the last sentence there? if this
> comes from PID1 then I'm guessing this is NOT cool!

yeah, i'd not be interested in having it it on the server side.

> I have to say tho', I'm surprised this is something implemented in PID1.
> I hadn't looked at the code, but I thought (well assumed) "systemctl
> preset" was actually implemented on the client side. I guess it's true
> what they say about "assume"... :p

Well, it's actually implemented on both sides (we link the same code
into client and server), so that --root= can work, and so that it can be
invoked if systemd is not running as PID 1. However, during normal
workflow it's only ever executed from PID 1.

> > 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?
> 
> Well, the rationale is that this can be done globally with filetriggers
> without actually having to do anything in the individual RPMs.
> 
> The current scriptlets in the rpm are just scripts from our rpm-helper
> package which currently call systemctl enable (after checking various
> lists of what to enable and disable - for us, we've had the equiv of
> preset for a number of years now - i.e. it's not "new" per-se, I'm just
> trying to phase it out in favour of something official). These scripts
> can all be plugged in with very minimal effort - i.e. we do not need to
> touch individual packages here - not even for a rebuild as they are
> separate scripts that are simply called from rpm, not embedded within
> it. We are a small team and thus these things take a long time to
> trickle through - I do want and aim for native units everwhere. But I
> guess it's also nice to have practical tests for the bits that are still
> supposed to work - even if they are "legacy"!
> 
> Anyway, it's interesting that you say the preset is actually something
> built into PID1. This will affect things quite a lot as it probably
> won't work as I expected (i.e. the same as the enable support) in
> certain environments - like our installer.

It should actually work (see above).

Lennart

-- 
Lennart Poettering, Red Hat