FS#44270 - cpupower: make systemd integration more generic
Attached to Project:
Community Packages
Opened by David Runge (dvzrv) - Friday, 20 March 2015, 01:25 GMT
Last edited by Sébastien Luttringer (seblu) - Sunday, 17 April 2016, 10:28 GMT
Opened by David Runge (dvzrv) - Friday, 20 March 2015, 01:25 GMT
Last edited by Sébastien Luttringer (seblu) - Sunday, 17 April 2016, 10:28 GMT
|
Details
Description: Upon the start of the cpupower systemd service,
the environment file is sourced from within the script. This
functionality can (and should be) completely done with
systemd in this case, because that way a simple copy and
paste (+ modifying) of the unit file is possible to direct
to a different environment file and thus achieve a more
generic and profile based setup for cpupower.
In the current case three separate files have to be copied and modified to achieve a profile based setup. Additional info: cpupower 3.19-1 I attached a patch, that will solve this by using EnvironmentFile in the service file and removing the sourcing of the configuration file from within the script. Note: Following this, no variable expansion will be possible within the configuration file (because of the way systemd handles Environments). But then again, that's probably nothing anyone would want to do there in the first place. 
generic-environment.patch
(0.7 KiB)
|
This task depends upon
Closed by Sébastien Luttringer (seblu)
Sunday, 17 April 2016, 10:28 GMT
Reason for closing: Implemented
Additional comments about closing: linux-tools 4.5-2
Sunday, 17 April 2016, 10:28 GMT
Reason for closing: Implemented
Additional comments about closing: linux-tools 4.5-2
Your patch reduce the number of file to modify from 3 to 2 but we cannot execute the script without systemctl.
A simple use-case would be:
On linux-rt I'd like to set my CPU governor to "performance", running the vanilla linux kernel I'd like to use "powersave".
Distinguishing between both kernels can be achieved with a modified copy of cpupower.service in /etc/systemd/system/ with trivial checks like "ConditionKernelCommandLine=<some-parameter-that-you-only-set-for-linux-rt>".
If you then set "After=cpupower.service", you will first start the "vanilla cpupower", and then the "rt cpupower" (only if on linux-rt). See this for reference: https://git.sleepmap.de/uenv.git/tree/system/cpupower-rt.service (here I'm creating a special service file, script and configuration for the use with linux-rt, to not conflict with current cpupower behavior).
For /usr/lib/systemd/scripts/cpupower though it doesn't matter when/where the used environment variables are set (as long as they are set). That's why you can just use EnvironmentFile=/etc/default/cpupower instead of hardcoding the sourcing of the configuration file into the script. By making the script and the service file generic, users will be able to just copy something like
[Unit]
Description=Apply cpupower configuration on a realtime kernel
ConditionKernelCommandLine=systemd.setenv=REALTIME=true
After=cpupower.service
[Service]
Type=oneshot
EnvironmentFile=/some/other/configuration
ExecStart=/usr/lib/systemd/scripts/cpupower
RemainAfterExit=yes
[Install]
WantedBy=multi-user.target
to /etc/systemd/system/some-other-cpupower.service and have it work just like the packaged one (with a separate configuration file).
Currently I would have to either modify /usr/lib/systemd/scripts/cpupower or create a script like /usr/lib/systemd/scripts/cpupower-somethingelse, to source a different configuration AND copy a modified version of cpupower.service to /etc.
I don't get what you mean by "we cannot execute the script without systemctl". Isn't this the whole point of scripts residing in /usr/lib/systemd/scripts/?
/usr/bin/cpupower is still (and hopefully always will be) completely standalone and the binary being used behind the scenes, when executing the systemd specific script.
IMHO the service/script should be as generic as possible and not restrict itself in the way it can be set. This change would make profile-based loading of cpupower much much easier.
One could even think about a cpupower@.service to directly source different configuration files. This would make the use of e.g. /etc/cpupower/someotherconfig.conf possible by just calling systemctl start cpupower@someotherconfig.service. The need is there! :)