picnoir
/
Systemd
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Systemd/src/test/test-sched-prio.c

80 lines
2.8 KiB
C
Raw Normal View History

Add SPDX license identifiers to source files under the LGPL This follows what the kernel is doing, c.f. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=5fd54ace4721fc5ce2bb5aef6318fcf17f421460.
2017-11-18 17:09:20 +01:00
/* SPDX-License-Identifier: LGPL-2.1+ */
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
/***
tree-wide: beautify remaining copyright statements Let's unify an beautify our remaining copyright statements, with a unicode ©. This means our copyright statements are now always formatted the same way. Yay.
2018-06-12 19:00:24 +02:00
Copyright © 2012 Holger Hans Peter Freyther
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
***/
#include <sched.h>
core: undo the dependency inversion between unit.h and all unit types
2018-05-15 20:17:34 +02:00
#include "all-units.h"
tests: skip bus test if bus cannot be opened To make the result more visible, special return value is used to tell automake that the test was skipped. While at it, use the same return value in other skipped tests.
2013-03-27 02:07:46 +01:00
#include "macro.h"
tree-wide: sort includes Sort the includes accoding to the new coding style.
2015-11-16 22:09:36 +01:00
#include "manager.h"
tests: override XDG_RUNTIME_DIR where we use the user runtime dir We don#t really support systems where XDG_RUNTIME_DIR is not supported for systemd --user. Hence, let's always set our own XDG_RUNTIME_DIR for tests that involve systemd --user, so that we know it is set, and that it doesn't polute the user's actual runtime dir.
2016-04-08 18:54:05 +02:00
#include "rm-rf.h"
tests: turn check if manager cannot be intialized into macro We need to check the same thing in multiple tests. Use a shared macro to make it easier to update the list of errnos. Change the errno code for "unitialized cgroup fs" for ENOMEDIUM. Exec format error looks like something more serious. This fixes test-execute invocation in mock.
2015-12-02 04:35:16 +01:00
#include "test-helper.h"
tests: override XDG_RUNTIME_DIR where we use the user runtime dir We don#t really support systems where XDG_RUNTIME_DIR is not supported for systemd --user. Hence, let's always set our own XDG_RUNTIME_DIR for tests that involve systemd --user, so that we know it is set, and that it doesn't polute the user's actual runtime dir.
2016-04-08 18:54:05 +02:00
#include "tests.h"
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
int main(int argc, char *argv[]) {
basic: remove rm_rf_and_free, add rm_rf_physical_and_free, use rm_rf_physical_and_freep in tests (#3292) Some distros don't mount /tmp as tmpfs. For example: https://lists.ubuntu.com/archives/ubuntu-cloud/2016-January/001009.html Some tests: * print 'Attempted to remove disk file system, and we can't allow that.' * don't really cleanup /tmp
2016-05-20 15:08:24 +02:00
_cleanup_(rm_rf_physical_and_freep) char *runtime_dir = NULL;
Introduce _cleanup_(manager_freep)
2018-03-09 21:55:55 +01:00
_cleanup_(manager_freep) Manager *m = NULL;
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
Unit *idle_ok, *idle_bad, *rr_ok, *rr_bad, *rr_sched;
Service *ser;
tests: skip tests if manager cannot be created When running without a user session, tests fail.
2013-02-06 23:35:53 +01:00
int r;
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
tests: use a helper function to parse environment and open logging The advantages are that we save a few lines, and that we can override logging using environment variables in more test executables.
2018-09-13 14:31:13 +02:00
test_setup_logging(LOG_INFO);
tests: skip tests when cg_pid_get_path fails (#7033) v2: - cast the fstype_t type to ull, because it varies between arches. Making it long long should be on the safe side.
2017-10-10 20:55:20 +02:00
r = enter_cgroup_subroot();
tests: add helper to unify skipping a test and exiting
2018-09-13 13:34:12 +02:00
if (r == -ENOMEDIUM)
return log_tests_skipped("cgroupfs not available");
tests: when running a manager object in a test, migrate to private cgroup subroot first (#6576) Without this "meson test" will end up running all tests in the same cgroup root, and they all will try to manage it. Which usually isn't too bad, except when they end up clearing up each other's cgroups. This race is hard to trigger but has caused various CI runs to fail spuriously. With this change we simply move every test that runs a manager object into their own private cgroup. Note that we don't clean up the cgroup at the end, we leave that to the cgroup manager around it. This fixes races that become visible by test runs throwing out errors like this: ``` exec-systemcallfilter-failing.service: Passing 0 fds to service exec-systemcallfilter-failing.service: About to execute: /bin/echo 'This should not be seen' exec-systemcallfilter-failing.service: Forked /bin/echo as 5693 exec-systemcallfilter-failing.service: Changed dead -> start exec-systemcallfilter-failing.service: Failed to attach to cgroup /exec-systemcallfilter-failing.service: No such file or directory Received SIGCHLD from PID 5693 ((echo)). Child 5693 ((echo)) died (code=exited, status=219/CGROUP) exec-systemcallfilter-failing.service: Child 5693 belongs to exec-systemcallfilter-failing.service exec-systemcallfilter-failing.service: Main process exited, code=exited, status=219/CGROUP exec-systemcallfilter-failing.service: Changed start -> failed exec-systemcallfilter-failing.service: Unit entered failed state. exec-systemcallfilter-failing.service: Failed with result 'exit-code'. exec-systemcallfilter-failing.service: cgroup is empty Assertion 'service->main_exec_status.status == status_expected' failed at ../src/src/test/test-execute.c:71, function check(). Aborting. ``` BTW, I tracked this race down by using perf: ``` # perf record -e cgroup:cgroup_mkdir,cgroup_rmdir … # perf script ``` Thanks a lot @iaguis, @alban for helping me how to use perf for this. Fixes #5895.
2017-08-09 15:42:49 +02:00
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
/* prepare the test */
test: remove support for suffix in get_testdata_dir() Instead, use path_join() in callers wherever needed.
2018-09-12 08:15:09 +02:00
assert_se(set_unit_path(get_testdata_dir()) >= 0);
test: setup test data dir before fake runtime dir That way, if the test directory does not exist we don't leave behind temporary files (as in that case or on test failure the cleanup actions don't run).
2017-02-14 22:33:52 +01:00
assert_se(runtime_dir = setup_fake_runtime_dir());
Make MANAGER_TEST_RUN_MINIMAL just allocate data structures When running tests like test-unit-name, there is not point in setting up the cgroup and signals and interacting with the environment. Similarly when running fuzz testing of the parser. Add new MANAGER_TEST_RUN_BASIC which takes the role of MANAGER_TEST_RUN_MINIMAL, and redefine MANAGER_TEST_RUN_MINIMAL to just create the basic data structures.
2018-03-10 11:02:18 +01:00
r = manager_new(UNIT_FILE_USER, MANAGER_TEST_RUN_BASIC, &m);
tests: add a helper function to skip with errno
2018-09-13 16:11:16 +02:00
if (MANAGER_SKIP_TEST(r))
return log_tests_skipped_errno(r, "manager_new");
test: only use assert_se The asserts used in the tests should never be allowed to be optimized away
2014-10-04 23:51:45 +02:00
assert_se(r >= 0);
tree-wide: pass NULL arguments to manager_startup() directly, avoid declaring unneeded variables
2018-06-20 22:19:26 +02:00
assert_se(manager_startup(m, NULL, NULL) >= 0);
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
/* load idle ok */
tests: use manager_load_startable_unit_or_warn() to load units Doing manager_load_unit() followed by UNIT_VTABLE(unit)->start(unit) would result in an assertion failure in ->start() if the unit failed to load properly. Something like this is okey-ish is tests, since the test units are not expected to fail to load, but the reason for failure is clearer if we fail immediately.
2018-04-12 15:51:39 +02:00
assert_se(manager_load_startable_unit_or_warn(m, "sched_idle_ok.service", NULL, &idle_ok) >= 0);
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
ser = SERVICE(idle_ok);
assert_se(ser->exec_context.cpu_sched_policy == SCHED_OTHER);
assert_se(ser->exec_context.cpu_sched_priority == 0);
/*
* load idle bad. This should print a warning but we have no way to look at it.
*/
tests: use manager_load_startable_unit_or_warn() to load units Doing manager_load_unit() followed by UNIT_VTABLE(unit)->start(unit) would result in an assertion failure in ->start() if the unit failed to load properly. Something like this is okey-ish is tests, since the test units are not expected to fail to load, but the reason for failure is clearer if we fail immediately.
2018-04-12 15:51:39 +02:00
assert_se(manager_load_startable_unit_or_warn(m, "sched_idle_bad.service", NULL, &idle_bad) >= 0);
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
ser = SERVICE(idle_ok);
assert_se(ser->exec_context.cpu_sched_policy == SCHED_OTHER);
assert_se(ser->exec_context.cpu_sched_priority == 0);
/*
* load rr ok.
* Test that the default priority is moving from 0 to 1.
*/
tests: use manager_load_startable_unit_or_warn() to load units Doing manager_load_unit() followed by UNIT_VTABLE(unit)->start(unit) would result in an assertion failure in ->start() if the unit failed to load properly. Something like this is okey-ish is tests, since the test units are not expected to fail to load, but the reason for failure is clearer if we fail immediately.
2018-04-12 15:51:39 +02:00
assert_se(manager_load_startable_unit_or_warn(m, "sched_rr_ok.service", NULL, &rr_ok) >= 0);
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
ser = SERVICE(rr_ok);
assert_se(ser->exec_context.cpu_sched_policy == SCHED_RR);
assert_se(ser->exec_context.cpu_sched_priority == 1);
/*
* load rr bad.
* Test that the value of 0 and 100 is ignored.
*/
tests: use manager_load_startable_unit_or_warn() to load units Doing manager_load_unit() followed by UNIT_VTABLE(unit)->start(unit) would result in an assertion failure in ->start() if the unit failed to load properly. Something like this is okey-ish is tests, since the test units are not expected to fail to load, but the reason for failure is clearer if we fail immediately.
2018-04-12 15:51:39 +02:00
assert_se(manager_load_startable_unit_or_warn(m, "sched_rr_bad.service", NULL, &rr_bad) >= 0);
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
ser = SERVICE(rr_bad);
assert_se(ser->exec_context.cpu_sched_policy == SCHED_RR);
assert_se(ser->exec_context.cpu_sched_priority == 1);
/*
* load rr change.
* Test that anything between 1 and 99 can be set.
*/
tests: use manager_load_startable_unit_or_warn() to load units Doing manager_load_unit() followed by UNIT_VTABLE(unit)->start(unit) would result in an assertion failure in ->start() if the unit failed to load properly. Something like this is okey-ish is tests, since the test units are not expected to fail to load, but the reason for failure is clearer if we fail immediately.
2018-04-12 15:51:39 +02:00
assert_se(manager_load_startable_unit_or_warn(m, "sched_rr_change.service", NULL, &rr_sched) >= 0);
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
ser = SERVICE(rr_sched);
assert_se(ser->exec_context.cpu_sched_policy == SCHED_RR);
assert_se(ser->exec_context.cpu_sched_priority == 99);
tests: skip tests if manager cannot be created When running without a user session, tests fail.
2013-02-06 23:35:53 +01:00
return EXIT_SUCCESS;
sched: Only setting CPUSchedulingPriority=rr doesn't work A service that only sets the scheduling policy to round-robin fails to be started. This is because the cpu_sched_priority is initialized to 0 and is not adjusted when the policy is changed. Clamp the cpu_sched_priority when the scheduler policy is set. Use the current policy to validate the new priority. Change the manual page to state that the given range only applies to the real-time scheduling policies. Add a testcase that verifies this change: $ make test-sched-prio; ./test-sched-prio [test/sched_idle_bad.service:6] CPU scheduling priority is out of range, ignoring: 1 [test/sched_rr_bad.service:7] CPU scheduling priority is out of range, ignoring: 0 [test/sched_rr_bad.service:8] CPU scheduling priority is out of range, ignoring: 100
2012-11-01 18:48:11 +01:00
}