Resolves: RHEL-15137
Appropriate commands are added to tuned-adm as well.
`get_instances`: Retrieves a list of active instances of a given
plugin or all active instances.
`instance_get_devices`: Retrieves a list of devices assigned
to a given instance.
Extends the runtime API by the method:
instance_acquire_devices(devices, instance_name)
E.g. consider the following TuneD profile:
[cpus_perf]
type=cpu
devices=cpu0, cpu1
governor=performance
[cpus_idle]
type=cpu
devices=${f:cpulist2devs:2-3}
governor=ondemand
[cpus_idle2]
type=cpu
devices=${f:cpulist2devs:4-5,7}
governor=ondemand
Notice that it's possible to use internal function 'cpulist2devs' to easily
specify cpulists.
After the following API call:
instance_acquire_devices("cpulist:2-5,7", "cpus_perf")
It will result in cpu0 - cpu5 and cpu7 having the "performance" governor.
It's also possible to specify full device names in the API instead of the
cpulist, e.g.:
instance_acquire_devices("cpu2,cpu3,cpu4,cpu5,cpu7", "cpus_perf")
In case the comma is part of the device name, it can be escaped by "\,".
In case the device name starts with the string "cpulist:", e.g. there is
by accident device named "cpulist:abcd", it's possible to use
"cpulist:cpulist:abcd" to escape it and don't recognize it as the cpulist.
The cpulist expand feature also supports bitmasks variant prefixed by the
0x and written as a string, e.g. "0xffffffff", i.e. all the standard
TuneD cpulist syntaxes are supported.
Resolves: rhbz#2113925
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
The 'D' is now capital to clarify pronunciation.
DBus service name is kept as '/Tuned' not to break
backward compatibility.
This will also need update of downstream tests
which rely on the specific output strings containing
the name.
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>
Currently, the post-loaded profile is shown only among regular active
profiles. For example:
Current active profile: balanced post
This is not entirely user-friendly, because the user may not know why
the post-loaded profile is there, given that they did not specify it
in a 'tuned-adm profile' command and given that it's not present in
/etc/tuned/active_profile.
To give the user a hint about this and also to make it easy to see
exactly which profile is post-loaded, we make 'tuned-adm active' show
the following:
Current active profile: balanced post
Current post-loaded profile: post
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
As these interfaces allow loading and thus executing code from plugins
the default permission policy is lowered from:
yes:yes:yes
to
auth_admin:auth_admin:yes
So only users logged into the X server are allowed to use this interface
without extra root/admin authentication.
This was found by security review by Matthias Gerstner
<matthias.gerstner@suse.com>
Also see:
https://github.com/redhat-performance/tuned/issues/180
Add two DBus calls:
log_capture_start(log_level, timeout)
* This will instruct Tuned to create a new log handler, which will
start writing log messages with level 'log_level' and higher to
a buffer. The log levels are standard Python log levels (e.g.
logging.INFO) or Tuned's custom log level LOG_LEVEL_CONSOLE which
is defined as 60. The handler will be destroyed after 'timeout' seconds
if contents of the buffer are not collected using log_capture_finish()
before the timeout. If 'timeout' <= 0, log messages will be collected
for as long as it takes before log_capture_finish() is called (use
with care, so that you don't fill up memory with Tuned logs). This
call returns a string ID of the log handler, a token, which should
be passed to log_capture_finish().
log_capture_finish(token)
* This will return (as a string) log messages collected by a log handler
associated with the 'token'. It will also destroy the log handler.
These calls are privileged. They can only be called by the root user or
by a user logged in on a local console (just like the change-profile DBus
calls). This restriction is meant to prevent ordinary users from forcing
Tuned to allocate an insane amount of memory for the log buffers and crash
it (or other processes). In the future we may wish to replace this
restriction with a configurable policy which determines how many (and how
big) log buffers can a user with a given UID create. We may also want to
destroy the log handler when the original caller disconnects from DBus.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Implement a new 'tuned-adm profile_mode' command, which prints
the current profile mode - automatic vs. manual.
Related: rhbz#1459146
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
A profile can now be set in two modes: automatic and manual.
When the automatic mode is active, Tuned always activates the
recommended profile upon startup. This mode can be set using
the following command:
tuned-adm auto_profile
When the manual mode is active, the previously applied profile
is activated upon startup. This mode can be set by switching
to the desired profile, e.g.
tuned-adm profile throughput-performance
The mode is saved on the second line of /etc/tuned/active_profile.
When the file /etc/tuned/active_profile does not exist, or is
empty, automatic mode is enabled. When the file has only one line,
i.e. it was generated by a previous Tuned version, manual mode
is enabled so that the upgrade doesn't cause unexpected active profile
changes.
Related: rhbz#1459146
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
The policy for running the 'verify_profile_ignore_missing' D-Bus method
was missing, so only root could run it. This commit adds the policy, so
that it is the same as the policy for regular 'verify_profile'.
Signed-off-by: Ondřej Lysoněk <olysonek@redhat.com>
Dropped dbus at_console policy and implemented polkit authorization.
By the default policy the query actions are allowed for all users, actions
which do modification to the system settings or Tuned state are by default
allowed only for active users that have console, others need admin
authorization.
Resolves: rhbz#1095142
Signed-off-by: Jaroslav Škarvada <jskarvad@redhat.com>