Re: [systemd-devel] systemctl preset and chkconfig
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
Re: [systemd-devel] systemctl preset and chkconfig
On Tue, Aug 26, 2014 at 3:56 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.08.14 08:59, Colin Guthrie (gm...@colin.guthr.ie) wrote: 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. What is then rationale for having it in PID 1 at all? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl preset and chkconfig
On Tue, 26.08.14 16:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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. What is then rationale for having it in PID 1 at all? So that we can provide it as a bus API. Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl preset and chkconfig
On Tue, Aug 26, 2014 at 4:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.08.14 16:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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. What is then rationale for having it in PID 1 at all? So that we can provide it as a bus API. And it *must* be in PID 1? Can it be systemd-install.service (pick the name)? ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl preset and chkconfig
В Tue, 26 Aug 2014 14:38:52 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 26.08.14 16:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Tue, Aug 26, 2014 at 4:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.08.14 16:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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. What is then rationale for having it in PID 1 at all? So that we can provide it as a bus API. And it *must* be in PID 1? Can it be systemd-install.service (pick the name)? Well, you can also just leave it in PID 1. What's the point? Normal service has more relaxed requirements. In particular, nothing really prevents it from supporting chkconfig :) ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl preset and chkconfig
On Tue, 26.08.14 21:58, Andrei Borzenkov (arvidj...@gmail.com) wrote: В Tue, 26 Aug 2014 14:38:52 +0200 Lennart Poettering lenn...@poettering.net пишет: On Tue, 26.08.14 16:37, Andrei Borzenkov (arvidj...@gmail.com) wrote: On Tue, Aug 26, 2014 at 4:34 PM, Lennart Poettering lenn...@poettering.net wrote: On Tue, 26.08.14 16:29, Andrei Borzenkov (arvidj...@gmail.com) wrote: 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. What is then rationale for having it in PID 1 at all? So that we can provide it as a bus API. And it *must* be in PID 1? Can it be systemd-install.service (pick the name)? Well, you can also just leave it in PID 1. What's the point? Normal service has more relaxed requirements. In particular, nothing really prevents it from supporting chkconfig :) Well, I don't think this would really change much. I don#t want to invoooke chkconfig on the server side, since it's not a tool for that, for example expects to be invoked with stdout/stderr connected to the user console, and I am not convinced we really should completely change the modus how we invoke it... Lennart -- Lennart Poettering, Red Hat ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
Re: [systemd-devel] systemctl preset and chkconfig
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... 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 ___ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
[systemd-devel] systemctl preset and chkconfig
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. 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
