On Tue, 26.08.14 08:59, Colin Guthrie (gm...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
