Lennart Poettering wrote on 26/08/14 02:19: > On Fri, 22.08.14 15:51, Colin Guthrie (gm...@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...
I presume you missed a negative in the last sentence there? if this comes from PID1 then I'm guessing this is NOT cool! 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 > 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. Will have to rethink using preset at all for now. Cheers! Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited http://www.tribalogic.net/ Open Source: Mageia Contributor http://www.mageia.org/ PulseAudio Hacker http://www.pulseaudio.org/ Trac Hacker http://trac.edgewall.org/ _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
