When profile recommender is executed without root privileges than
he can not execute virt-what to determine virt conditions in
recommend.d files. This caused several error messages which could
be confusing for user.
Add log of warning about this to profile recommender so user knows
exactly what is happening and why profiles with virt
recommendation condition are ommited from recommendation process
when user has not root privileges.
Behaviour of recommend process has not been changed.
Signed-off-by: Tomas Korbar <tkorbar@redhat.com>
The effective UID is what matters when it comes to the ability to
perform privileged actions, not the real UID.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Execute method from Commands class takes array of strings as
arguments to execute not a name of executable.
This caused bad format of logged error message in case of failure
of execute method.
Signed-off-by: Tomas Korbar <tkorbar@redhat.com>
In commit 0d28f9e63e, verification has been accidentally
dropped from the _custom_parameters method. Fix it.
Fixes#135
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Starting with commit 0d28f9e63e, values that have been applied
were stored instead of the original values, which broke rollback. Fix it
by storing the actual original values.
Fixes#135
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
When i moved recommend functionality to its own class i did not
notice that 'tuned-adm recommend' command uses it from commands
class when tuned daemon is not running
Added ProfileRecommender to imports and changed old calls
Resolves: rhbz#1687397
Signed-off-by: Tomas Korbar <tkorbar@redhat.com>
If "recommends" is not supported do not use "requires" for
python/python3 dmidecode, because dmidecode is not available on
all architectures.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
This happend because of insufficient testing of folders in tuned
profile directories
GuiProfileLoader now makes sure folder contains profile by
checking if folder contains tuned.conf file
Signed-off-by: Tomas Korbar <tkorbar@redhat.com>
Unfortunately non-required subcommands are not supported by argparse
module on python2, so selection between plugins and profiles must be
done by new positional non-required arguments "profiles" and
"plugins"
Examples of usage:
$ tuned-adm list -- will list tuned profiles like before
$ tuned-adm list profiles -- new command which has the same function
as tuned-adm list
$ tuned-adm list plugins -- will list tuned accessible plugins
$ tuned-adm list plugins [-v|--verbose] -- will list tuned accessible
plugins + their configuration options and hints how to use them
Signed-off-by: Tomas Korbar <tkorbar@redhat.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>
If a device, namely a disk, is hotplugged after tuned is started, it
won't be present in Monitor._available_devices. Consequently, it won't
get added to the monitor and so dynamic tuning won't work for the
device. Let's fix that by refreshing the list of available devices when
adding a device to a monitor.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
_remove_unused_filters() is not used anywhere and the udev's
remove_filter() is broken anyway:
https://github.com/systemd/systemd/issues/11529
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Hiding the full stack trace in the debug output is not useful - it hides
information that would be useful for us when diagnosing a failure. It's
not always possible (and it's certainly an unnecessary burden for the
users) to later reproduce the issue with debug mode on. As a bonus, the
traceback will now stand out in the log, increasing the likelihood
that it will get noticed and reported.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fallback to the 'powersave' CPU scaling governor if 'ondemand' is
not available. This can happen if the intel_pstate driver is active - at
least on newer kernels, the only available governors are 'powersave' and
'performance' if the driver is active.
As far as we can tell, the 'powersave' governor is the closest to the
'ondemand' governor.
Resolves: rhbz#1679205
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Fallback to the 'powersave' CPU scaling governor if 'conservative' is
not available. This can happen if the intel_pstate driver is active - at
least on newer kernels, the only available governors are 'powersave' and
'performance' if the driver is active.
As far as we can tell, the 'powersave' governor is the closest to the
'conservative' governor.
Resolves: rhbz#1679205
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The 'governor' option of the 'cpu' plugin now supports specifying
multiple governors. The governors are separated using '|' (the '|'
character is meant to represent a logical 'or' operator; we already use
the same syntax for the 'energy_perf_bias' option). Tuned will set
the first governor that is available on the system.
For example, with the following profile, Tuned will set the 'ondemand'
governor, if it's available. If it's not available, but the 'powersave'
governor is available, 'powersave' will be set. If neither of them are
available, the governor will not be changed.
[cpu]
governor=ondemand|powersave
Resolves: rhbz#1679205
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Since commit cd4943bdbf, it is recommended to use ${i:PROFILE_DIR}
in paths to scripts, in order to make the paths absolute. So let's make
the profile generated by powertop2tuned conform to that recommendation.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Since commit cd4943bdbf, it is recommended to use ${i:PROFILE_DIR}
in paths to scripts, in order to make the paths absolute. It's not
required (yet) though.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
