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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The original workaround didn't work, as `systemd-repart` kept failing
even when the `/dev/loopX` device was present:
```
[ 13.959419] H testsuite-58.sh[280]: + LOOP=/dev/loop1
[ 13.959636] H testsuite-58.sh[280]: + :
[ 13.959764] H testsuite-58.sh[280]: + test -e /dev/loop1
[ 13.959895] H testsuite-58.sh[280]: + break
[ 13.960023] H testsuite-58.sh[280]: + systemd-repart --pretty=yes --definitions=/tmp/testsuite-58-sector/ --seed=750b6cd5c4ae4012a15e7be3c29e6a47 --empty=require --dry-run=no /dev/loop1
[ 13.970538] H testsuite-58.sh[363]: Device '/dev/loop1' has no dm-crypt/dm-verity device, no need to look for underlying block device.
[ 13.970538] H testsuite-58.sh[363]: Failed to determine canonical path for '/dev/loop1': No such file or directory
[ 13.970538] H testsuite-58.sh[363]: Failed to open file or determine backing device of /dev/loop1: No such file or directory
```
On arm, we'd fail with:
target@v:5.16.8-200.fc35.armv7hl+lpae.socket: not a valid unit name "target@v:5.16.8-200.fc35.armv7hl+lpae.socket": Invalid argument
Inspired by 7910ec3bcd.
'! true' passes, because it's a conditional expression.
But '( ! true )' fails, because '( … )' creates a subshell, i.e. a separate
program, and '! true' becomes the return value of that program, and the whole
thing apparently is not a conditional expression for the outer shell.
This is shorter, so let's just do this.
We would only accept "identical" links, but having e.g. a symlink
/usr/lib/systemd/system/foo-alias.service → /usr/lib/systemd/system/foo.service
when we're trying to create /usr/lib/systemd/system/foo-alias.service →
./foo.service is OK. This fixes an issue found in ubuntuautopkg package
installation, where we'd fail when enabling systemd-resolved.service, because
the existing alias was absolute, and (with the recent patches) we were trying
to create a relative one.
A test is added.
(For .wants/.requires symlinks we were already doing OK. A test is also
added, to verify.)
When we have a symlink that goes outside of our search path, we should just
ignore the target file name. But we were verifying it, and rejecting in
the case where a symlink was created manually.
This is a fairly noticable change, but I think it needs to be done.
So far we'd create an absolute symlink to the target unit file:
.wants/foo.service → /usr/lib/systemd/system/foo.service
or
alias.service → /etc/systemd/system/aliased.service.
This works reasonably well, except in one case: where the unit file
is linked. When we look at a file link, the name of the physical file
isn't used, and we only take the account the symlink source name.
(In fact, the destination filename may not even be a well-formed unit name,
so we couldn't use it, even if we wanted to.) But this means that if
a file is linked, and specifies aliases, we'd create absolute links for
those aliases, and systemd would consider each "alias" to be a separate
unit. This isn't checked by the tests here, because we don't have a running
systemd instance, but it is easy enough to check manually.
The most reasonable way to fix this is to create relative links to the
unit file:
.wants/foo.service → ../foo.service
alias.service → aliased.service.
I opted to use no prefix for aliases, both normal and 'default.target',
and to add "../" for .wants/ and .requires/. Note that the link that is
created doesn't necessarily point to the file. E.g. if we're enabling
a file under /usr/lib/systemd/system, and create a symlink in /etc/systemd/system,
it'll still be "../foo.service", not "../../usr/lib/systemd/system/foo.service".
For our unit loading logic this doesn't matter, and figuring out a path
that actually leads somewhere would be more work. Since the user is allowed
to move the unit file, or add a new unit file in a different location, and
we don't actually follow the symlink, I think it's OK to create a dangling
symlink. The prefix of "../" is useful to give a hint that the link points
to files that are conceptually "one level up" in the directory hierarchy.
With the relative symlinks, systemd knows that those are aliases.
The tests are adjusted to use the new forms. There were a few tests that
weren't really testing something useful: 'test -e x' fails if 'x' is a
a dangling symlink. Absolute links in the chroot would be dangling, even
though the target existed in the expected path, but become non-dangling
when made relative and the test fails.
This should be described in NEWS, but I'm not adding that here, because
it'd likely result in conflicts.
I was considering deduplicating the list of target units in
WantedBy/RequiredBy. But to do this meaningfully, we'd need to do alias
expansion first, i.e. after the initial parsing is done. This seems to be
more trouble than it would be worth.
Instead, I added tests that we're doing the right thing and creating symlinks
as expected. For duplicate links, we create the link, and on the second time we
see that the link is already there, so the output is correct.
We'd create aliases and other symlinks first, and only then try to create
the main link. Since that can fail, let's do things in opposite order, and
abort immediately if we can't link the file itself.
We don't need to talk about Alias=. The approach of using Alias= to enable
units is still supported, but hasn't been advertised as the way to do thing
for many years. Using it as an explanation is just confusing.
Also, the description of templated units did not take DefaultInstance=
into account. It is updated and extended.
We had a check that was done in unit_file_resolve_symlink(). Let's move
the check to unit_validate_alias_symlink_or_warn(), which makes it available
to the code in install.c.
With this, unit_file_resolve_symlink() behaves almost the same. The warning
about "suspicious symlink" is done a bit later. I think this should be OK.
So far we'd issue a warning (before this series, just in the logs on the server
side, and before this commit, on stderr on the caller's side), but return
success. It seems that successfull return was introduced by mistake in
aa0f357fd8 (my fault :( ), which was supposed to
be a refactoring without a functional change. I think it's better to fail,
because if enablement fails, the user will most likely want to diagnose the
issue.
Note that we still do partial enablement, as far as that is possible. So if
e.g. we have [Install] Alias=foo.service foobar, we'll create the symlink
'foo.service', but not 'foobar', since that's not a valid unit name. We'll
print info about the action taken, and about 'foobar' being invalid, and return
failure.
We would resolve those specifiers to the calling user/group. This is mostly OK
when done in the manager, because the manager generally operates as root
in system mode, and a non-root in user mode. It would still be wrong if
called with --test though. But in systemctl, this would be generally wrong,
since we can call 'systemctl --system' as a normal user, either for testing
or even for actual operation with '--root=…'.
When operating in --global mode, %u/%U/%g/%G should return an error.
The information whether we're operating in system mode, user mode, or global
mode is passed as the data pointer to specifier_group_name(), specifier_user_name(),
specifier_group_id(), specifier_user_id(). We can't use userdata, because
it's already used for other things.
ENOENT is easily confused with the file that we're working on not being
present, e.g. when the file contains %o or something else that requires
os-release to be present. Let's use -EUNATCH instead to reduce that chances of
confusion if the context of the error is lost.
And once we have pinpointed the reason, let's provide a proper error message:
+ build/systemctl --root=/tmp/systemctl-test.TO7Mcb enable some-some-link6@.socket
/tmp/systemctl-test.TO7Mcb/etc/systemd/system/some-some-link6@.socket: Failed to resolve alias "target@A:%A.socket": Protocol driver not attached
Failed to enable unit, cannot resolve specifiers in "target@A:%A.socket".
The test for the variable is added in test-systemctl-enable because there we
can do it almost for free, and the variable is most likely to be used with
'systemctl enable --root' anyway.
This test has overlap with test-install-root, but it tests things at a
different level, so I think it's useful to add. It immediately shows various
bugs which will be fixed in later patches.
A reattach might go from img.raw to img_0.1.raw or viceversa, but this is
not allowed right now as we try to match the full name.
Also take into account that running strcspn(a, '/') on an image name, without
leading path, will return the length of the full string, but the versions
might be different so they won't match, eg:
img_0.1.raw -> 12
img_0.1.1.raw -> 14
So adjust the check to take that into account, and skip it if we are not
dealing with directories
On a very slow machine, things are executed out-of-order, and something
pins the previously-exited unit. Instead of fighting with this with daemon-reload,
let's just use a different cleanup unit.
Hopefully fixes#22755.
"meson test" uses a test name generated from the file name and those long names
cause the test log output to exceed terminal width which looks bad. Let's replace
some long names with more-meaningful names that actually say something about
the tests.
Add tests for enrolling and unlocking. Various cases are tested:
- Default PCR 7 policy w/o PIN, good and bad cases (wrong PCR)
- PCR 7 + PIN policy, good and bad cases (wrong PCR, wrong PIN)
- Non-default PCR 0+7 policy w/o PIN, good and bad cases (wrong PCR 0)
v2: rename test, fix tss2 library installation, fix CI failures
v3: fix ppc64, load module
It seems there exists a short time period that we cannot see the
loopback device after `losetup` is finished:
```
testsuite-58.sh[367]: ++ losetup -b 1024 -P --show -f /tmp/testsuite-58-sector-1024.img
kernel: loop1: detected capacity change from 0 to 204800
testsuite-58.sh[285]: + LOOP=/dev/loop1
testsuite-58.sh[285]: + systemd-repart --pretty=yes --definitions=/tmp/testsuite-58-sector/ --seed=750b6cd5c4ae4012a15e7be3c29e6a47 --empty=require --dry-run=no /dev/loop1
testsuite-58.sh[368]: Device '/dev/loop1' has no dm-crypt/dm-verity device, no need to look for underlying block device.
testsuite-58.sh[368]: Failed to determine canonical path for '/dev/loop1': No such file or directory
testsuite-58.sh[368]: Failed to open file or determine backing device of /dev/loop1: No such file or directory
```
The Ubuntu CI on ppc64el seems to have a issue on tmpfs, and files
may not be fsynced. See c10caebb98.
For safety, let's use /var/tmp to store disk images.
Unprivileged overlayfs is supported since Linux 5.11. The only
change needed to get ExtensionDirectories to work is to avoid
hard-coding the staging directory to the system manager runtime
directory, everything else just works (TM).
The first ExecStartPre or the first ExecStart commands would get the metadata,
but not the subsequent ones. Also check that we do not pass it in
ExecStartPost.
The test would fail when the the same handler was used for multiple
*failing* units. We need to call 'reset-failed' to let the manager forget
about the earlier ones.
systemd-analyze log-target console is removed, because it's easier to follow
the logs if logging it to the journal.
Remove the list logic, and simply skip passing metadata if more than one
unit triggered an OnFailure/OnSuccess handler.
Instead of a single env var to loop over, provide each separate item
as its own variable.
Fixes https://github.com/systemd/systemd/issues/22370
The only piece missing was to somehow make /proc appear in the
new user+mount namespace. It is not possible to mount a new
/proc instance, not even with hidepid=invisible,subset=pid, in
a user namespace unless a PID namespace is created too (and also
at the same time as the other namespaces, it is not possible to
mount a new /proc in a child process that creates a PID namespace
forked from a parent that created a user+mount namespace, it has
to happen at the same time).
Use the host's /proc with a bind-mount as a fallback for this
case. User session services would already run with it, so
nothing is lost.
On Ubuntu CI on ppc64el, the test randomly fails when /run/udev is not
synced before checking its contents (see #22357). But /run/udev is a
tmpfs and fsync on tmpfs is noop (see `struct shmem_file_operations` in
mm/shmem.c of the kernel), hence, it is not necessary to call fsync on
/run/udev in general. This should be a testing emvironment issue (I
guess it is an issue on nested KVM on ppc64el), instead of an issue on
udev.
C.f. #22357.
Fixes#21603.
In some BIOSes, the "Number of slots or sockets available for Memory
Devices in this array" is incorrectly set to the number of memory array
that's populated.
Work-around this problem by outputting the number of sockets after
having parsed them so that consumers of this data can carry on expecting
an accurate number in this property.
This fixes the number of memory slots advertised for the HP Z600.
See https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/1686
IIUC, pipefail doesn't matter for a sequence of commands joined with &&, and we
don't have any pipes. And such a failing expression also does not trigger an
exit, so the set +e/set -e were noops.
Make sure our RPM macros work as intended. Based on the original PR
(#16464) by Mikhail Novosyolov.
Co-authored-by: Mikhail Novosyolov <m.novosyolov@rosalinux.ru>
Add support for managing and configuring watchdog pretimeout values if
the watchdog hardware supports it. The ping interval is adjusted to
account for a pretimeout so that it will still ping at half the timeout
interval before a pretimeout event would be triggered. By default the
pretimeout defaults to 0s or disabled.
The RuntimeWatchdogPreSec config option is added to allow the pretimeout
to be specified (similar to RuntimeWatchdogSec). The
RuntimeWatchdogPreUSec dbus property is added to override the pretimeout
value at runtime (similar to RuntimeWatchdogUSec). Setting the
pretimeout to 0s will disable the pretimeout.
There is no reason networkd refuses that. Especially, when multiple
downstream interfaces are connected to the same network, it is natural to
assign the same subnet prefix to them.
Prompted by #22571.
It should make it easier to figure out what exactly services do there.
For example, with SYSTEMD_LOG_LEVEL=debug userdbd (v249) prints
```
varlink-5: New incoming message: {"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{}}
```
before it crashes and systemd-resolved prints
```
varlink-21: New incoming message: {"method":"io.systemd.Resolve.ResolveAddress","parameters":{"address":[127,0,0,1],"flags":0,"ifindex":1000000,"family":0}}
```
and those messages are helpful (especially when scripts causing them
aren't clever enough to keep track of random stuff they send to systemd
:-))
If we assign our own test runner, passing arguments stops working
as unittest won't instantiate its own test runner after it parses
the arguments from sys.argv.
Consequence is that the tests will write to stderr now instead of
stdout since it doesn't seem possible to configure the stream that
unittest.main() will instantiate its test runner with so it'll
default to sys.stderr.
otherwise units using `DynamicUser=yes` won't be able to write the
coverage stats (currently affecting TEST-20-MAINPIDGAMES).
`DynamicUser=yes` implies `ProtectSystem=strict` and
`ProtectHome=read-only` and can't be overridden hence we need to
utilize `ReadWritePaths=` to work around that.
If the test logs contain lines like:
```
...systemd-resolved[735885]: profiling:/systemd-meson-build/src/shared/libsystemd-shared-250.a.p/base-filesystem.c.gcda:Cannot open
```
it means we're possibly missing some coverage since gcov can't write the stats,
usually due to the sandbox being too restrictive (e.g. ProtectSystem=yes,
ProtectHome=yes) or the $BUILD_DIR being inaccessible to non-root users.
Every time I need it I have to first relearn autopkgtest and find where
all the necessary stuff lives, so let's document it somewhere close to
systemd for (at least) future me.
In cbcdcaaa0e ("Add support for conditions on the machines firmware")
a new Firmware= directive was added for .netdev and .network files.
While it was also documented to work on .link files, in actual fact the
support was missing. Add that one extra line to make it work, and also
update the fuzzer directives.
Add the "Isolated" parameter in the *.network file, e.g.,
[Bridge]
Isolated=true|false
When the Isolated parameter is true, traffic coming out of this port
will only be forward to other ports whose Isolated parameter is false.
When Isolated is not specified, the port uses the kernel default
setting (false).
The "Isolated" parameter was introduced in Linux 4.19.
See man bridge(8) for more details.
But even though the kernel and bridge/iproute2 recognize the "Isolated"
parameter, systemd-networkd did not have a way to set it.
The warning is correct, since we don't inherit the necessary
unittest.TestCase class, but that's on purpose, since the Utilities
class is not supposed to be instantiated on its own, but should
complement other classes' definitions which do inherit from the
unittest.TestCase class.
It currently works because `\(` and `\)` are not valid escape sequences,
so they're not treated differently. Using raw strings (or double
backslashes) is a more correct solution.
Multiline comments are converted to docstrings only when they're the
first statement in a function/method. Even though they're still a no-op
otherwise, let's use "true" comments to make pylint happy.
to let them use reproducible identifiers, which should make it possible
to really use files copied from OSS-Fuzz to reproduce issues on
GHActions and locally. Prompted by https://github.com/systemd/systemd/pull/22365
If we're built with `-Dportable=false`, the portable profiles won't get
installed into the image. Since we need only the profile files and
nothing else, let's copy them into the image explicitly in such case.
/etc/bash.bashrc appears to be Debian-specific[0] (or specific to bash
versions compiled with -DSYS_BASHRC), which doesn't seem to be the case
for C8S. Let's use ~/.bashrc instead to make the CIs happy again.
[0] https://sources.debian.org/src/bash/5.1-6/debian/README/#L50-L56
Turns out that part of systemd isn't covered by any fuzz targets and
that's not ideal considering that it parses data sent remotely. The
fuzzer triggers an infinite loop in lease_parse_routes as soon as it
starts so it seems to be working :-)
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 23620602
INFO: Loaded 2 modules (182073 inline 8-bit counters): 176548 [0x7fdf511fc8d0, 0x7fdf51227a74), 5525 [0x5f6ef0, 0x5f8485),
INFO: Loaded 2 PC tables (182073 PCs): 176548 [0x7fdf51227a78,0x7fdf514d94b8), 5525 [0x5f8488,0x60ddd8),
./build/fuzz-dhcp-client: Running 1 inputs 1 time(s) each.
Running: test/fuzz/fuzz-dhcp-client/timeout-ed34161922c7075c4773f2ada3dee8685d220980
ALARM: working on the last Unit for 31 seconds
and the timeout value is 30 (use -timeout=N to change)
==80731== ERROR: libFuzzer: timeout after 31 seconds
#0 0x51b32e in __sanitizer_print_stack_trace (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51b32e)
#1 0x4689e9 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x4689e9)
#2 0x44a0f4 in fuzzer::Fuzzer::StaticAlarmCallback() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a0f4)
#3 0x7fdf4f8b474f (/lib64/libc.so.6+0x4274f)
#4 0x465fee in __sanitizer_cov_trace_const_cmp4 (/home/vagrant/systemd/build/fuzz-dhcp-client+0x465fee)
#5 0x57eee5 in lease_parse_routes /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:495:23
#6 0x57baf3 in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:701:21
#7 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
#8 0x571cea in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:381:21
#9 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
#10 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:78:9
#11 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
#12 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
#13 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
#14 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
#15 0x7fdf4f89f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
#16 0x7fdf4f89f60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
#17 0x421fd4 in _start (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421fd4)
SUMMARY: libFuzzer: timeout
```
A bind mount is added directly from private on the host to the actual
destination directory, no need for the symlinks (which cannot be created
as the bind mount happens first and creates the target as an actual directory)
Fixes https://github.com/systemd/systemd/issues/22264
If wait_operstate() is called super quickly after ip command, then the
up/down state may not be changed and propagated to networkd, and
wait_operstate() mistakenly pass with the previous state.
To avoid such situation, wait for a while to make networkd actually
detect the interface brought up/down.
This fixes the following race:
1. when a dummy interface is created, it is initially down state,
2. hence, wait_operstate() may pass before the link is activated,
3. and the ip command bring up the interface before the activation,
4. and networkd activates, that is, brings down the interface,
5. thus, next wait_operstate() timedout, as it waits for the interface up.
To fix the race, let's wait the link is activated, before enter the loop
of wait_operstate().
Fixes#22267.
Since the TEST-64-UDEV-STORAGE fails are quite frequent now and the root
cause is yet to be discovered, let's add a kludge that attempts to retry
the test up to two more times in case it fails, so we don't
unnecessarily disturb CIs while the issue is being investigated.
Revert this commit once #21819 is sorted out.
Tests DnsStream event handling, both for plain TCP DNS and DNS over TLS.
The DoT test requires the "openssl s_server" command line tool to mock a simple
TLS server. Thus the test's TLS part is skipped if openssl it not available.
The test works for both DNS_OVER_TLS_USE_GNUTLS and DNS_OVER_TLS_USE_OPENSSL.
The DoT case fails due to a bug, which is fixed on the next commit.
When a Condition*= fails, and a service has Restart=always,
the service is not restarted.
Follow the same behaviour for ExecCondition= to avoid inconsistencies.
Fixes#22257
The script was probably not used for a very long time. It is currently
passed systemd_boot.so as boot loader, which cannot work. The test
entries it creates are all pointing at non-existant efi/linux binaries,
which means they would not even show up in the menu if the created image
were actually booted. There is also nothing that actually tries to run
the image in the first place.
If we end up creating a proper systemd-boot test suite, it would be
better to start from scratch. In the meantime, mkosi already covers
the bare minimum with a simple bootup test.
Wraps nspawn to be able to use pexpect. The test logs in on the console
and runs screen. In one screen window it types in shutdown commands and
checks whether a wall message was sent to the other.
Currently, running "meson build" followed by "meson test -C build"
will result in many failed tests due to missing dependencies. This
commit adds the missing dependencies to make sure no tests fail.
Add a new setting that follows the same principle and implementation
as ExtensionImages, but using directories as sources.
It will be used to implement support for extending portable images
with directories, since portable services can already use a directory
as root.
Strictly speaking, this breaks the backward compatibility, but I guess
in most cases people already sets Scope=link for such routes.
This behavior matches with how 'ip route' command adds such route by
default.
Prompted by https://twitter.com/jplitza/status/1480500562391179270.
No need to invoke ls when we are just interested in file names.
Also, the cd to source root makes the output identical to
"git ls-files" (relative instead of absolute paths).
Dangling symlinks get pruned when packaging up the installation
directory. Just store empty files instead, and compare the names
rather than the content for .requires/.wants - the filename is
what is important anyway, the content is ignored.
Fixes#22059
Otherwise we might hit a window where the coredump happens before
midnight, but we check for it after midnight, which yields no results.
E.g.:
```
$ coredumpctl --no-legend --no-pager --file system.journal
Wed 2022-01-05 01:00:06 CET 359 0 0 SIGABRT journal /usr/bin/udevadm n/a
$ coredumpctl --since 23:59:55 --no-legend --no-pager --file system.journal
No coredumps found.
$ coredumpctl --since "2022-01-04 23:59:59" --no-legend --no-pager --file system.journal
Wed 2022-01-05 01:00:06 CET 359 0 0 SIGABRT journal /usr/bin/udevadm n/a
```
