IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
* test: check resolved generated resolv.conf in networkd-test
Directly verify the contents of /run/systemd/resolve/resolv.conf instead of
/etc/resolv.conf. The latter might be a plain file or a symlink to something
else (like Debian's resolvconf output), and in these cases we cannot make
strong assumptions about the contents.
Drop the "/etc/resolv.conf is a symlink" conditions and the "resolv.conf can
have at most three nameservers" alternatives, as we know that resolved always
adds all nameservers.
Explicitly start resolved at the start of a test to ensure that it is running.
* test: get along with existing system search domains in resolv.conf
The previous change has uncovered a bug in the tests: Existing search domains
can exist in resolv.conf which test_search_domains{,_too_long} didn't take into account.
As existing domains take some of the "max 6 domains" and "max 255 chars" limit,
don't expect that the last items from our test data actually appears in the
output, just the first few.
With commit 6f7da49d00 route-only domains do not get put into resolv.conf's
"search" list any more. Add a comment about the tri-state, to clarify its
semantics and why we are passing a bool parameter into an int type. Also add a
test case for it.
If run_qemu() exits with non-zero, this either meant that QEMU was not
available (which should be a SKIP) or that QEMU timed out if $QEMU_TIMEOUT was
set (which then should be a FAIL).
Limit the exit code of run_qemu() to QEMU availability only, and track timeouts
separately through the new $TIMED_OUT variable, which is then checked in
check_result_qemu().
Do the same for $NSPAWN_TIMEOUT and run_nspawn() so that nspawn and QEMU work
similarly.
The result of check_nspawn does not mean much, and this forgot to ask
check_nspawn() whether nspawn can be used at all. This brings
TEST-12-ISSUE-3171 in line with other nspawn tests.
The long name is just too hard to type. We generally should avoid using
acronyms too liberally, if they aren't established enough, but it appears that
"RA" is known well enough. Internally we call the option "ipv6_accept_ra"
anyway, and the kernel also exposes it under this name. Hence, let's rename the
IPv6AcceptRouterAdvertisements= setting and the
[IPv6AcceptRouterAdvertisements] section to IPv6AcceptRA= and [IPv6AcceptRA].
The old setting IPv6AcceptRouterAdvertisements= is kept for compatibility with
older configuration. (However the section [IPv6AcceptRouterAdvertisements] is
not, as it was never available in a published version of systemd.
There are many cgroups-related changes (thanks, @htejun!)
This commit will simplify testing a bit.
Use:
make run UNIFIED_CGROUP_HIERARCHY=yes to enable cgroup-v2
make run UNIFIED_CGROUP_HIERARCHY=no to enable cgroup-v1
Write comments about "too many search domains" and "Total length of all search
domains is too long" just once. Also put it on a separate line, as
resolv.conf(5) only specifies comments in a line by themselves.
This is ugly to do if write_resolv_conf_search() gets called once for every
search domain. So change it to receive the complete OrderedSet instead and do
the iteration by itself.
Add test cases to networkd-test.py.
https://launchpad.net/bugs/1588229
Due to the substantial interface changes in cgroup unified hierarchy, new IO
settings are introduced. Currently, IO settings apply only to unified
hierarchy and BlockIO to legacy. While the transition is necessary, it's
painful for users to have to provide configs for both. This patch implements
translation from one config set to another for configs which make sense.
* The translation takes place during application of the configs. Users won't
see IO or BlockIO settings appearing without being explicitly created.
* The translation takes place only if there is no config for the matching
cgroup hierarchy type at all.
While this doesn't provide comprehensive compatibility, it should considerably
ease transition to the new IO settings which are a superset of BlockIO
settings.
v2:
- Update test-cgroup-mask.c so that it accounts for the fact that
CGROUP_MASK_IO and CGROUP_MASK_BLKIO move together. Also, test/parent.slice
now sets IOWeight instead of BlockIOWeight.
In this test /etc/fstab is replaced by -.mount unit. This causes
systemd-remount-fs.service to not remount / rw, which in turn causes various
failures becuase /var is not writable. In particular
systemd-tmpfiles-setup.service reports many failures. This is something
to possibly fix on its own (see https://github.com/systemd/systemd/issues/791);
in the meanwhile let's fix this test so that it doesn't fail, since the
point of the test is to check aliases on mount units, and not a ro root.
systemd-udev generated an insane amount of log output at debug level.
It would break TEST-02-CRYPTSETUP by filling the overflowing the disk
(which seems to be a bug in itself!).
WARNING: Image format was not specified for
'/var/tmp/systemd-test.tGi3od/rootdisk.img' and probing guessed raw.
Automatically detecting the format is dangerous for raw images, write
operations on block 0 will be restricted. Specify the 'raw' format
explicitly to remove the restrictions.
Also use unsafe caching mode, we don't care about data integrity here.
~ suffix works fine, but looks to much like it the file is supposed to be
automatically cleaned up. For new versions of configuration files installers
might want to using something that looks more permanent like foobar.new.
So let's add treat ".old" and ".new" as special.
Update test to match.
Fixes:
$ cd test/TEST-07-ISSUE-1981/
$ sudo make clean setup run
...
timeout: failed to run command ‘systemd-nspawn’: No such file or directory
...
TEST RUN: https://github.com/systemd/systemd/issues/1981 [FAILED]
Makefile:10: recipe for target 'run' failed
make: *** [run] Error 1
Add two more tests:
- Add a single tag, match on it, don't match on another.
- Add 10.000 tags to a device, ensure that udev survives this.
(Reproduces crash fixed by commit 1d88a271a)
The manpage of seccomp specify that using seccomp with
SECCOMP_SET_MODE_FILTER will return EACCES if the caller do not have
CAP_SYS_ADMIN set, or if the no_new_privileges bit is not set. Hence,
without NoNewPrivilege set, it is impossible to use a SystemCall*
directive with a User directive set in system mode.
Now, NoNewPrivileges is set if we are in user mode, or if we are in
system mode and we don't have CAP_SYS_ADMIN, and SystemCall*
directives are used.
It's useful when trying to see what the tests are doing.
I hardcoded '-efile' as the option to strace, but in the future
it might be useful to make this configurable.
If there is a lot of initscripts and dependencies between them we might
end generating After= (and similar) lines which are longer then LINE_MAX
and thus rejected by parser in systemd.
Fixes#2099
* Use $ROOTLIBDIR/systemd always
* Don't pass $ROOTLIBDIR/systemd as the first argument:
$ cat /proc/1/cmdline
/lib/systemd/systemd/lib/systemd/systemd...
This uses temporary configuration in /run and temporary veth devices, and does
not write anything on disk or change any system configuration; but it assumes
(and checks at the beginning) that networkd is not currently running.
This can be run on a normal installation, in QEMU, nspawn, or LXC.
As this requires root privileges, this is not integrated into "make check".
Fixes backward/forward incompatibility errors on spawning.
For example:
$ sudo make run
...
Failed to register machine: Cannot set property TasksMax, or unknown
property.
$ ../../systemd-nspawn --version
systemd 228
$ systemd-nspawn --version
systemd 225
Sempaphore containers are not booted with systemd, so machined is not
available, which makes nspawn bail. Just skip nspawn tests in such
environments.
[ -d /run/systemd/system ] is esentially what sd_booted(3) is doing,
but on Ubuntu 15.05, without 'systemd-container' installed, we also
need to check for the presence of the systemd-machined binary.
Fixes:
systemd-testsuite systemd[34]: PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth
systemd-testsuite systemd[34]: PAM _pam_load_conf_file: unable to open /etc/pam.d/system-auth
systemd-testsuite systemd[34]: user@0.service: Failed at step PAM spawning /lib/systemd/systemd: Operation not permitted
...
on Debian, Ubuntu
Fixes:
systemd-testsuite login[31]: cannot open login definitions /etc/login.defs [No such file or directory]
systemd-testsuite systemd[1]: Received SIGCHLD from PID 31 (login).
systemd-testsuite systemd[1]: Child 31 (login) died (code=exited, status=1/FAILURE)
systemd-testsuite systemd[1]: console-getty.service: Child 31 belongs to console-getty.service
systemd-testsuite systemd[1]: console-getty.service: Main process exited, code=exited, status=1/FAILURE
systemd-testsuite systemd[1]: console-getty.service: Changed running -> dead
on Debian/Ubuntu
Useful on other distros
libpam_modules installs modules into /lib/$(dpkg-architecture -qDEB_HOST_MULTIARCH)/security
on Debian
Fixes:
systemd-testsuite login[36]: PAM unable to dlopen(pam_group.so): /lib/security/pam_group.so: cannot open shared object file: No such file or directory
systemd-testsuite login[36]: PAM adding faulty module: pam_group.so
systemd-testsuite login[36]: PAM unable to dlopen(pam_limits.so): /lib/security/pam_limits.so: cannot open shared object file: No such file or directory
systemd-testsuite login[36]: PAM adding faulty module: pam_limits.so
...
etc
Fixes:
systemd[39]: systemd-exit.service: Executing: /bin/kill -s 58 29
systemd[39]: systemd-exit.service: Failed at step EXEC spawning /bin/kill: No such file or directory
systemd[29]: Received SIGCHLD from PID 39 ((kill)).
systemd[29]: Child 39 ((kill)) died (code=exited, status=203/EXEC)
Check the base case, plus erasing the list, listing the same variable
name more than once and when variables are absent from the manager
execution environment.
Confirmed that `sudo ./test-execute` passes and that modifying the test
cases (or the values of the set variables in test-execute.c) is enough
to make the test cases fail.
* remove journal flushing (systemd-journal-flush.service runs journalctl --flush on boot)
* use sh -c and PATH instead of @SYSTEMCTL@ expansion
* remove unnecessary semicolons etc
In most cases, systemd requires escaping $ (for systemd variable
substitution) and % (for specifiers) by doubling them. This was somewhat
of an issue in tests like exec-environment*.service where systemd was
doing the substitutions and we were not really checking that those were
available in the actual environment of the command. Fix that.
Expressions such as `exit $(test ...)` are incorrect. They only work
because $(test ...) will produce no output, so the command will become a
bare "exit" which will exit with the status of the latest executed
command which turns out to be the test... The direct approach is simply
calling "test" as the last command, for which the shell will propagate
the exit status.
One situation where this was breaking tests was on `exit $(test ...) &&
$(test ...) && $(test ...)` where the second and third tests were not
really executing, since the first command is actually `exit` so && was
doing nothing there. Fixed it by just using `test ... && test ... &&
test ...` as it was initially intended.
Pass -x to all shell executions for them to produce useful debugging
output to stderr. Consequently, removed most of the explicit `echo`s
that are no longer needed.
Mark all units as Type=oneshot explicitly.
Also made sure all shell variables are properly quoted.
v2: Added an explicit LC_ALL=C to ionice invocations since some locales
(such as French) will add a space before the colon in the output.
Tested by running `sudo ./test-execute` and confirming all tests enabled
on my system (essentially all of them except for the s390 one) passed.
Tweaked the variables or options or expected values and confirmed the
tests do indeed fail when the values are not exactly the expected ones.
v2: Also tested with `LANG=fr_FR.UTF-8 sudo ./test-execute` to confirm
it still works in a different locale.
The basic setup for the well-known system and session buses is
now done in read-only files in ${datadir} (normally /usr/share).
See the NEWS entry for 1.9.18 for details.
http://cgit.freedesktop.org/dbus/dbus/tree/NEWS
When Group is set in the unit, the runtime directories are owned by
this group and not the default group of the user (same for cgroup paths
and standard outputs)
Fix#1231
It is more accurate to report that the test was skipped rather than
succeeded if we did not get to run it because it requires root.
Tested by running `make check` and inspecting the log file:
$ cat test/udev-test.pl.log
Must have root permissions to run properly.
SKIP test/udev-test.pl (exit status: 77)
The `make check` output also reported:
SKIP: test/udev-test.pl
test_simple_escaped() sometimes fails with
AssertionError: Lists differ: ['foo\\x2b.service', 'foo-admin.service'] != ['foo-admin.service', 'foo\\x2b.service']
We don't need to assume any order here, so compare them as a set, not a list.
Set $SYSTEMD_LOG_TARGET so that the output always goes to stdout/stderr. This
fixes running the test as root, as that logged to the journal previously.
https://github.com/systemd/systemd/issues/195
Fix result testing of is_symlink() to ignore negative results, which happen if
the file name does not exist at all. In this case we do not want a warning and
unlink the non-existing link.
https://bugs.debian.org/778700
Commit d5d8429a dropped the explicit runlevelN.target mapping. Adjust the tests
accordingly to explicitly state the expected targets instead of runlevels.
What used to be gummiboot, was renamed sd-boot when it was merged into
systemd. Let's try to be a bit more consistent with the rest of systemd
and rename it again as follows:
The EFI bootloader is now called 'systemd-bootx64.efi', and its sources are in
'src/boot/efi/'. The drop-in directory where bootctl will find EFI loaders
is now /usr/lib/systemd/boot/efi/.
This avoids taking the SysV init script enablement state into account if we
have native units. Otherwise systemctl disable on native unit would not
be respected in the presence of an enabled SysV script.
Also, there's no need to do all the parsing and creation of service files if we
already have a native systemd unit for the processed SysV init script.
Prefer asking pkg-config for the rootlibdir, to also support systems with
--enable-split-usr. Fall back to the hardcoded /usr/lib/systemd if that fails.
Since commit b7e7184 the SysV generator creates symlinks for all "Provides:" in
the LSB header. However, this is too greedy; there are cases where the
creation of a unit .service file fails because of an already existing
symlink with the same name:
- Backup files such as /etc/init.d/foo.bak still have "Provides: foo", and
thus get a foo.service -> foo.bak.service link. foo.bak would not be enabled
in rcN.d/, but we (deliberately) create units for all executables in init.d/
so that a manual "systemctl start" works. If foo.bak is processed before,
the symlink already exists.
- init.d/bar has "Provides: foo", while there also is a real init.d/foo. The
former would create a link foo.service -> bar.service, while the latter
would fail to create the real foo.service.
If we encounter an existing symlink, just remove it before writing a real unit.
Note that two init.d scripts "foo" and "bar" which both provide the same name
"common" already work. The first processed init script wins and creates the
"common.service" symlink, and the second just fails to create the symlink
again. Thus create an additional test case for this to ensure that it keeps
working sensibly.
https://bugs.debian.org/775404
When deciding whether the provided name equals the file name in
sysv_translate_facility(), also consider them equal if the file name has a
".sh" suffix.
This was uncovered by commit b7e7184 which then created a symlink
"<name>.service" to itself for ".sh" suffixed init.d scripts.
For additional robustness, refuse to create symlinks to itself in add_alias().
Add test case which reproduces the bug.
https://bugs.debian.org/775889
Drop globbing of rules/*.rules in the rules-test.sh wrapper and move that logic
into the actual test rule-syntax-check.py. This can still be called with
individual rules files, but when being called without arguments it will now
process all top_builddir/rules/*.rules.
Preparation for dropping the shell wrappers altogether.
add tests for the following directives:
- WorkingDirectory
- Personality
- IgnoreSIGPIPE
- PrivateTmp
- SystemCallFilter: It makes test/TEST-04-SECCOMP obsolete, so it has
been removed.
- SystemCallErrorNumber
- User
- Group
- Environment
It tests all available directives of Path units:
- PathChanged
- PathModified
- PathExists
- PathExisysGlob
- DirectoryNotEmpty
- MakeDirectory
- DirectoryMode
- Unit
Instead of operating on an sd_bus_message object, expose an API that has 4
functions:
policy_check_own()
policy_check_hello()
policy_check_recv()
policy_check_send()
This also allows dropping extra code to parse message contents - the bus
proxy already has dedicated code paths for that, and we can hook into
those later.
Tests amended accordingly.
We now verify the existence of uid's before applying them to devicenodes, so change the
test accordingly. We assume that both uid/gid 1 and 2 exist on the test system.
A unit should not Conflict with itself. It also does not make
much sense for a unit to be After or Before itself, or to
trigger itself in some way.
If one of those dependency types is encountered, warn, instead
of dropping it silently like other dependency types.
% build/systemd-analyze verify test/loopy3.service
...
Dependency Conflicts dropped when merging unit loopy4.service into loopy3.service
Dependency ConflictedBy dropped when merging unit loopy4.service into loopy3.service
Also add a bit of debugging output to help diagnose problems,
add missing units, and simplify cppflags.
Move test-engine to normal tests from manual tests, it should now
work without destroying the system.
It tries to find a suitable QEMU binary and will use KVM if present.
We can now configure QEMU from outside with 4 variables :
- $QEMU_BIN : path to QEMU's binary
- $KERNEL_APPEND : arguments appended to kernel cmdline
- $KERNEL_BIN : path to a kernel
Default /boot/vmlinuz-$KERNEL_VER
- $INITRD : path to an initramfs
Default /boot/initramfs-${KERNEL_VER}.img
- $QEMU_SMP : number of CPU simulated by QEMU.
Default 1
(from Alexander Graf's script: http://www.spinics.net/lists/kvm/msg72389.html)
- fix typo
- use compiled systemd-nspawn
- drop --capability=... from systemd-nspawn invocation, is is the default now
- simplify sudo make invocations
Add a test case for job merging with --ignore-dependencies.
test.sh is copied from TEST-01-*, only lightly modified (this
should be refactored better in the future).
test-jobs.sh is the core of this test.
Tests can use the same testsuite.target.
Add end.service to call poweroff instead of doing it from ExecStopPost
where it may be skipped on failure of ExecStart.
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
$ cd test
$ sudo make check
will run all tests in the TEST-* subdirectories
$ cd test/TEST-01-BASIC
$ sudo make clean setup run
will run the different stages of the test for debugging purposes
