This fixes regression introduced by 74c3d35d7a.
Added safety check, that the custom directory from which the initrd is
generated has to owned by the same user who is running the TuneD.
Also dropped redundant "error:" prefix from some related error messages.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
This will not completely resolve RHEL-60906, because there will be
always race condition if the rename event happens before the instance
is fully initialized, but it should significantly improve the situation.
Drawback is that it can report in the logs device names that shouldn't
be matched by the plugin_net instance, i.e. it matches devices according
to their original names but accesses them with their new names. This
can be confusing. Also in the runtime API (e.g. for removal of the
device from the instance), the original device names have to be used.
For insertion of the device to the instance, new names have to be used.
This can be even more confusing.
Unfortunately, there probably isn't better alternative now, because
for correct operation we would have to handle rename by removal and
addition events. This would require rollback and retune steps which would
lead to very negative performance consequences. Also we would have to
cope with partially tuned devices if the rename event happens during
profile application. It's doable, but it would require big
architectural changes.
The PR also extends internal API, now the plugin instances receive
'instance' as a method parameter.
Also fixed some existing CodeQL warnings.
Resolves: RHEL-60906
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Need to expand variables before calling the @command function. This is
actually done for _execute_all[_non]_device_commands and
_verify_all_non_device_commands, but not in _verify_all_device_commands.
This adds the missing expansion.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
Currently instance priorities are only used at startup to sort the
instance classes. To enable dynamic creation of instances, we need
to store the priorities, so new instances can be sorted accordingly.
Signed-off-by: Adriaan Schmidt <adriaan.schmidt@siemens.com>
It requires slight internal plugin API change, thus 3rd party plugins
needs updating.
Namely the 'command_set' methods for devices were extended by the
'remove' boolean parameter which is set to 'True' on the hotplug remove
event. Then the method should silent the ENOENT errors where
appropriate, because the device interface may be removed (by
kernel/udev) before the method finishes.
Resolves: RHEL-11342
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Add rollback option to tuned-main.conf file. The option specifies how
TuneD should perform rollbacks. By default, the old behaviour is
preserved (rollback=auto) and settings are rolled back on TuneD daemon
exit and profile switches. Using rollback=not_on_exit will result in
TuneD not performing any rollbacks on the daemon exit, however, on
profile switches, settings rollbacks will still be performed.
Resolves: rhbz#2203142
Signed-off-by: Jiri Mencak <jmencak@users.noreply.github.com>
When verifying tuning, we need to iterate over the
instance.processed_devices set. That set is modified by the
MonitorObserver thread when a new device is added to the system.
If the device is added to the set while the set is being iterated,
it results in an exception:
RuntimeError: Set changed size during iteration
One possible solution would be to acquire a lock before accessing the
set, however that could hold up the MonitorObserver thread
unnecessarily. It's better to just take a copy of the set. We don't
really care if the instance.processed_devices set changes during the
iteration.
Resolves: rhbz#1592743
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
This patch fixes (at least) the following race conditions:
1. If a device is attached while iterating assigned devices, the
MonitorObserver thread can attempt to insert the newly attached
device to the assigned_devices set while the set is being iterated,
which results in the following exception:
RuntimeError: Set changed size during iteration
2. Some devices can be missed when applying a tuning - devices are enumerated
(i.e., Plugin._init_devices() gets called) before udev device monitoring is
started (hotplug.Plugin._hardware_events_init() gets called), so devices
that appear between these two actions are not tuned.
3. Device monitoring is stopped too late, which can result in some tunings
not being unapplied after stopping a profile. This can happen for devices
that get added during profile rollback after unit_manager.stop_tuning()
gets called, but before unit_manager.destroy_all() gets called.
4. It can happen that tuning is applied twice for a device if it is added
during profile activation, e.g. after unit_manager.create() is called in
Daemon._thread_code(), but before unit_manager.start_tuning() is called.
Apart from unnecessarily applying the tuning twice, it can result in
overwriting saved original settings for the device and hence our inability
to properly roll back our changes to the settings.
5. The observer thread can attempt to use load_monitor before it's created
in Plugin._instance_init(), which can result in AttributeError.
Hopefully it doesn't introduce new race conditions :).
The fix is to:
1. rearrange the sequence of certain actions,
2. separate Instance.devices to two separate sets: processed_devices
and assigned_devices.
processed_devices are never iterated when the MonitorObserver thread
is running (*), so the first problem described above cannot happen.
The set is used to store devices, which have already been tuned.
The assigned_devices set is now the set of devices that are going
to be tuned. The set can only be accessed by the main thread.
(*) Except when verifying tuning - this is fixed in a follow-up patch
I tried to separate the changes into more digestable patches, but I
couldn't figure out how.
Resolves: rhbz#1592743
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
these changes will protect tuned's execution thread from errors
caused by changes of instance's devices list while execution
thread iterates over them
fix problem with bad recognition of disk caused
by use of python3
Resolves: rhbz#1592743
Support specifying alternative Energy Performance Bias values.
The values are separated using the '|' character. For example,
if you have the following in your profile:
[cpu]
energy_perf_bias=powersave|power
then tuned will try to set EPB to 'powersave', and if that fails,
it will try to set it to 'power'.
Resolves: rhbz#1508468
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Previously verifying the value of a cpumask on systems with more than
32 cores always failed. There are two reasons for this:
1. When there are more than 32 cores, string comparison is done on the
cpu masks. This failed because the value read from sysfs contained
a line feed and was not stripped.
2. The cpumask value was not properly normalized when the value had multiple
non-zero comma separated parts, e.g. '00ffffff,80808000'
Resolves: rhbz#1528368
Take the ignore_missing parameter into account in @command_get methods
so that error messages are not logged for missing files.
In some @command_get methods the ignore_missing parameter is not used,
because e.g. it is not applicable or the parameter is handled elsewhere
in the code.
Resolves: rhbz#1451435
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
With systemd full rollback is done if Tuned is terminated by user or profile
is changed. It is not done if Tuned is terminated due to system
shutdown / reboot. Without systemd full rollback is done only if profile
is changed.
Renamed profile_switch parameter to full_rollback where appropriate.
Also fixed various checks for command not found.
Resolves: rhbz#1421286
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
All units (however only device-based plugins make sense) can now be
given the 'script_pre' and 'script_post' options.
The script referenced by 'script_pre' is run before applying and
verifying static tuning and 'script_post' is run after applying and
verifying. Durring unapplying tuning, the scripts are run in reversed
order, i.e. 'script_post' before unapplying and 'script_pre' after
unapplying static tuning.
The scripts are run for each device with the following arguments.
For apply:
script.sh apply <device_name>
For verify:
script.sh verify <device_name>
For unapply (the 'profile_switch' argument is given iff we're unapplying
tuning due to a profile switch):
script.sh unapply [profile_switch] <device_name>
Additinally, instances of hotplug plugins call the scripts when a device
is added/removed with the apply/unapply argument, the same way as shown
above.
The paths to the scripts must be absolute, you can use the ${i:PROFILE_DIR}
function to fill in the profile directory. The scripts are run with
the working directory set to the directory the scripts are in.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Introduced the ${i:PROFILE_DIR} internal function, which can be used
in profiles and which expands to the directory in which the profile
configuration was found. It replaces the workdir option, which
was a bit problematic due to inheritance and the possibility
to change its value.
The ability to change the value of 'workdir' seems redundant,
as the same effect can be achieved by either specifying an absolute
path to files in unit configuration or by using a user defined
variable.
Note that now you need to specify an absolute path or use the
${i:PROFILE_DIR} functin in the initrd_add_dir and initrd_add_img
options of the bootloader plugin.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Clean up device and non-device commands it reversed order, compared to
the order in which they were applied. It makes more sense that way to me.
Related: rhbz#1246176
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Also updated the core Tuned engine to support instance.workdir to get
the directory name the profile was loaded from.
Related: rhbz#1414098
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The bootloader plugin now supports the following options:
initrd_add_img=IMAGE
initrd_add_dir=DIR
initrd_dst_img=PATHNAME
The 'initrd_add_img' adds initrd overlay named IMAGE. The IMAGE is
added from the current profile directory. If IMAGE begins with '/' it's
taken as absolute path (e.g. initrd_add_img="/root/overlay.img").
The 'initrd_add_dir' creates initrd image from the DIR at first and then
adds the image as a overlay. The DIR is taken from the current profile
directory. If DIR begins with '/' it's taken as absolute path.
The 'initrd_dst_img' sets the name and location of the resulting initrd
image. Usually it is not needed to set it. By default the location of
initrd images is /boot and the name of the image is taken as a basename
of IMAGE or DIR. This can be overridden by 'initrd_dst_img'
Currently grub2-mkconfig doesn't support initrd overlays, so the initrd
settings are lost after 'grub2-mkconfig -o /boot/grub2/grub.cfg' is
issued. There is grub2 RFE bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=1427899
Resolves: rhbz#1414098
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
A new option 'devices_udev_regex' can be used in profile
configuration to specify devices to which a plugin instance
should be applied.
The option can contain a python regular expression, as specified
in https://docs.python.org/2/library/re.html#regular-expression-syntax.
The expression is effectively matched against the output of
udevadm info --query=property -n <device_path>
If the option 'devices_udev_regex' is specified, the 'devices' option
is ignored. If it is not specified, then the matching is done the same
way as previously, i.e. against 'devices'.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The _device attribute should always be the same as the union of
_assigned_devices and _free_devices, therefore it's redundant.
Its existence in my opinion brings only confusion and a potential
source of inconsistencies.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
I.e.
[myaudio]
type=audio
Will show in log as:
myaudio (audio)
and:
[audio]
Will show in log as:
audio
I.e. if the instance name and the plugin name is the same it will
not log the plugin name in braces.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Resolves: rhbz#1246172
Allow specifying order in which individual plugin instances are to be
executed.
Each instance can be given the 'instance_priority' option
in the profile configuration. The value must be an integer (it can be
negative). If no priority is specified, it is inherited from the parent
profile, or set to the default instance priority, if no parent profile
specifies the priority for that instance.
The default instance priority is by default zero, but it can be set to
a different value using the 'default_instance_priority' option in the
global configuration file.
Creating plugin instances, assigning devices to instances, initializing
instances, applying, updating and verifying tuning are all done in order
from lowest numerical instance priority to highest. Unapplying tuning and
destroying instances is done in reversed order.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The verify command can now be run in ignore-missing mode. In this mode
missing/non-supported settings (i.e. those which current value is None)
are ignored and not treated as errors.
The tuned-adm got new verify options -i and --ignore-missing which
enables the ignore-missing mode, usage:
tuned-adm verify -i
or:
tuned-adm verify --ignore-missing
The DBus interface got new method 'verify_profile_ignore_missing' which
does the verification in ignore-missing mode.
Resolves: rhbz#1243807
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Unquoting first and last quotation mark in value, i.e. converting:
OPTION="VALUE" to OPTION=VALUE
Also added unquoting to profile verification, unquoting both
(current and requested) values.
Resolves: rhbz#1254538
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
On some platforms the 'recommend' functionality doens't make sense
as there is only one product variant. On such platforms the recommend
functionality can be disabled by adding/changing the following in
the global config (/etc/tuned/tuned-main.conf):
recommend_command = 0
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Variables can be defined in [variables] section in profile configuration.
Variables are specified the following way:
[variables]
VARIABLE1 = VALUE1
VARIABLE2 = VALUE2
Variables are expanded on definition and assignment. Previously defined variable
is redefined by its new definition.
Variables can be referenced in plugins configuration by using '$' prefix, e.g.:
[variables]
delay = 20
[audio]
timeout = $delay
There can be also included external file with definition of variables by using
'include' directive:
[variables]
include = filename
The 'filename' is processed by ConfigObj parser. Comments are supported by '#'
character. Multiple sections are not supported and files with multiple sections
are flattened to single section configuration file.
The variables are also supported by the script plugin. It exports variables into
environment before the script is executed. The variable names are prefixed by
the 'TUNED_' string. Example:
[variables]
VARIABLE1 = VALUE1
will be exported into environment as:
TUNED_VARIABLE1 = VALUE1
If there is already TUNED_ prefix in the variable name, no other prefix is
added, i.e.:
[variables]
TUNED_VARIABLE1 = VALUE1
will be exported as:
TUNED_VARIABLE1 = VALUE1
and not TUNED_TUNED_VARIABLE1.
Resolves: rhbz#1225124
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
They were intended to be class methods and that's why there
were defined with the 'cls' parameter, but they actually
weren't class methods.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
At first try to compare current and new values as integers. If it fails
try to compare them as hexadecimal values. If it fails compare them
as strings.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Also added helper get_bool() function to utils. It can parse
variour boolean representations (e.g. from sysfs) and returns
string "0" for false and string "1" for true. If it cannot
parse boolean value, it returns original string.
Also fixed comparison of values for verify command in
plugins base class. Now it explicitly converts the values
to strings.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
