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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
'! grep -v' does *not* test that there are no matching lines.
Instead, it checks that whether there are any non-matching lines.
And of course, for the test to fail, '! grep' cannot be part of
an expression with &&.
We were grepping for 'hello world', and in the namespace we would
match on 'hello world', and outside, on 'echo "hello world"'. When
the condition check was fixed, the test gave a false positive.
We were invoking 'systemd-run bash', but the test invoked by bash
was not effective. When the result of that check is propagated, the
outer command fails.
create_fifo() was added in a2fc2f8dd3, and
would always ignore failure. The test was trying to fail in this case, but
we actually don't fail, which seems to be correct. We didn't notice before
because the test was ineffective.
To make things consistent, generally log at warning level, but don't propagate
the error. For symlinks, log at debug level, as before.
For 'e', failure is not propagated now. The test is adjusted to match.
I think warning is appropriate in most cases: we do not expect a device node to
be replaced by a different device node or even a non-device file. This would
most likely be an error somewhere. An exception is made for symlinks, which are
mismatched on purpose, for example /etc/resolv.conf. With this patch, we don't
get any warnings with the any of the 74 tmpfiles.d files, which suggests that
increasing the warning levels will not cause too many unexpected warnings. If
it turns out that there are valid cases where people have expected mismatches
for non-symlink types, we can always decrease the log levels again.
Quoting of values differs between distros: Fedora doesn't quote the ID_
fields, but CentOS does.
Adjust the test checks to account for this.
Fixes#19242
"! test ..." does not cause the script to fail, even with set -e.
IIUC, bash treats this command as part of an expression line, as it
would if 'test ... && ...' was used. Failing expression lines do not
terminate the script.
This fixes the obvious cases by changing '! test' → 'test !'.
Then the inversion happens internally in test and bash will propagate
the failure.
Add an --extension parameter to portablectl, and new DBUS methods
to attach/detach/reattach/inspect.
Allows to append separate images on top of the root directory (os-release
will be searched in there) and mount the images using an overlay-like
setup (unit files will be searched in there) using the new ExtensionImages
service option.
Add 'reattach' verb to portablectl, and corresponding DBUS interface
to systemd-portabled.
Takes the same parameters as 'attach', but it will do a 'detach' (and
it will refuse to proceed if it cannot be done) first, matching on
the unversioned prefix of the new image. Eg:
portablectl reattach /tmp/foo_2.raw
will cause foo_1.raw to be detached, and foo_2.raw to be attached.
The key difference with a manual 'detach old' plus 'attach new' is that
the running units are not disturbed until after the attach completed,
and if --now is passed they are then restarted.
A 'detach' is not allowed normally if the units are running.
By using a restart-after-deploy method, 'reattach' allows for minimal
interruption of service and also for features that only work on restart
(eg: file descriptor store) to work as intended.
The DBUS interface returns two lists: first the removals from the detach
that were not immediately re-added in the attach, so that the caller
can stop the relevant units, and then the list of additions that are
either new or updates, so that the caller can restart/enable the
relevant units. portablectl already implements this with the existing
--now/--enable switches.
There may be situations where a cgroup should be protected from killing
or deprioritized as a candidate. In FB oomd xattrs are used to bias oomd
away from supervisor cgroups and towards worker cgroups in container
tasks. On desktops this can be used to protect important units with
unpredictable resource consumption.
The patch allows systemd-oomd to understand 2 xattrs:
"user.oomd_avoid" and "user.oomd_omit". If systemd-oomd sees these
xattrs set to 1 on a candidate cgroup (i.e. while attempting to kill something)
AND the cgroup is owned by root, it will either deprioritize the cgroup as
a candidate (avoid) or remove it completely as a candidate (omit).
Usage is restricted to root owned cgroups to prevent situations where an
unprivileged user can set their own cgroups lower in the kill priority than
another user's (and prevent them from omitting their units from
systemd-oomd killing).
Allow to setup new bind mounts for a service at runtime (via either
DBUS or a new 'systemctl bind' verb) with a new helper that forks into
the unit's mount namespace.
Add a new integration test to cover this.
Useful for zero-downtime addition to services that are running inside
mount namespaces, especially when using RootImage/RootDirectory.
If a service runs with a read-only root, a tmpfs is added on /run
to ensure we can create the airlock directory for incoming mounts
under /run/host/incoming.
machinectl fails since 21935150a0 as it's now
mounting onto a file descriptor in a target namespace, without joining the
target's PID namespace.
Note that it's not enough to setns CLONE_NEWPID, but a double-fork is required
as well, as implemented by namespace_fork().
Add a test case to TEST-13-NSPAWN to cover this use case.
This adds the ability to specify truncate:PATH for StandardOutput= and
StandardError=, similar to the existing append:PATH. The code is mostly
copied from the related append: code. Fixes#8983.
The commit 6f3ac0d517 drops the prefix and
suffix in TAGS= property. But there exists several rules that have like
`TAGS=="*:tag:*"`. So, the property must be always prefixed and suffixed
with ":".
Fixes#17930.
Fixes#17533
The memory pressure values of the units in TEST-56-OOMD seemed to be a
lot lower after updating to linux 5.9. This is likely due to a fix from
e22c6ed90a.
To account for this, I lowered memory.high on testbloat.service to
throttle it even more. This was enough to generate the 50%+ value to trigger
oomd for the test, but as an extra precaution I also lowered the oomd
threshold to 1% so it's certain to try and kill testbloat.service.
When tests are executed serially (the default), it seems better to launch
the fairly generic test that runs the unittests early in the sequence.
Right now the tests are ordered based on when they were written, but
this doesn't make much sense.
We have four legal cases:
1. /usr/lib/os-release exists and /etc/os-release is a symlink to it
2. both exist but /etc/os-release is not a symlink to /usr/lib/os-release
3. only /usr/lib/os-release exists
4. only /etc/os-release exists
The generic setup code in test-functions and create-busybox-image didn't handle
case 3.
The test-specific code in TEST-50 didn't handle 2 (because the general setup
code would only install /etc/os-release in the image and
grep -f /usr/lib/os-release would not work) and 4 (same reason) and would fail
in case 3 in generic setup.
Follow the same model established for RootImage and RootImageOptions,
and allow to either append a single list of options or tuples of
partition_number:options.
The sd_notify() socket that nspawn binds that the payload can use to
talk to it was previously stored in /run/systemd/nspawn/notify, which is
weird (as in the previous commit) since this makes /run/systemd
something that is cooperatively maintained by systemd inside the
container and nspawn outside of it.
We now have a better place where container managers can put the stuff
they want to pass to the payload: /run/host/, hence let's make use of
that.
This is not a compat breakage, since the sd_notify() protocol is based
on the $NOTIFY_SOCKET env var, where we place the new socket path.
Follows the same pattern and features as RootImage, but allows an
arbitrary mount point under / to be specified by the user, and
multiple values - like BindPaths.
Original implementation by @topimiettinen at:
https://github.com/systemd/systemd/pull/14451
Reworked to use dissect's logic instead of bare libmount() calls
and other review comments.
Thanks Topi for the initial work to come up with and implement
this useful feature.
Allows to specify mount options for RootImage.
In case of multi-partition images, the partition number can be prefixed
followed by colon. Eg:
RootImageOptions=1:ro,dev 2:nosuid nodev
In absence of a partition number, 0 is assumed.
Let's find the right os-release file on the host side, and only mount
the one that matters, i.e. /etc/os-release if it exists and
/usr/lib/os-release otherwise. Use the fixed path /run/host/os-release
for that.
Let's also mount /run/host as a bind mount on itself before we set up
/run/host, and let's mount it MS_RDONLY after we are done, so that it
remains immutable as a whole.
Opening a verity device is an expensive operation. The kernelspace operations
are mostly sequential with a global lock held regardless of which device
is being opened. In userspace jumps in and out of multiple libraries are
required. When signatures are used, there's the additional cryptographic
checks.
We know when two devices are identical: they have the same root hash.
If libcrypsetup returns EEXIST, double check that the hashes are really
the same, and that either both or none have a signature, and if everything
matches simply remount the already open device. The kernel will do
reference counting for us.
In order to quickly and reliably discover if a device is already open,
change the node naming scheme from '/dev/mapper/major:minor-verity' to
'/dev/mapper/$roothash-verity'.
Unfortunately libdevmapper is not 100% reliable, so in some case it
will say that the device already exists and it is active, but in
reality it is not usable. Fallback to an individually-activated
unique device name in those cases for robustness.
The kernel interface requires setting up read-only bind-mounts in
two steps, the bind first and then a read-only remount.
Fix nspawn-mount, and cover this case in the integration test.
Fixes#16484
When the RTC time at boot is off in the future by a few days, OnCalendar=
timers will be scheduled based on the time at boot. But if the time has been
adjusted since boot, the timers will end up scheduled way in the future, which
may cause them not to fire as shortly or often as expected.
Update the logic so that the time will be adjusted based on monotonic time.
We do that by calculating the adjusted manager startup realtime from the
monotonic time stored at that time, by comparing that time with the realtime
and monotonic time of the current time.
Added a test case to validate this works as expected. The test case creates a
QEMU virtual machine with the clock 3 days in the future. Then we adjust the
clock back 3 days, and test creating a timer with an OnCalendar= for every 15
minutes. We also check the manager startup timestamp from both `systemd-analyze
dump` and from D-Bus.
Test output without the corresponding code changes that fix the issue:
Timer elapse outside of the expected 20 minute window.
next_elapsed=1594686119
now=1594426921
time_delta=259198
With the code changes in, the test passes as expected.
Several recent failed runs show that the test is still racy in two ways:
1) Sometimes it takes a while before the PID file is created, leading
to:
```
[ 10.950540] testsuite-47.sh[308]: ++ cat /leakedtestpid
[ 10.959712] testsuite-47.sh[308]: cat: /leakedtestpid: No such file or directory
[ 10.959824] testsuite-47.sh[298]: + leaked_pid=
```
2) Again, sometimes we check the leaked PID before the unit is actually
stopped, leading to a false negative:
```
[ 18.099599] testsuite-47.sh[346]: ++ cat /leakedtestpid
[ 18.116462] testsuite-47.sh[333]: + leaked_pid=342
[ 18.117101] testsuite-47.sh[333]: + systemctl stop testsuite-47-repro
...
[ 20.033907] testsuite-47.sh[333]: + ps -p 342
[ 20.080050] testsuite-47.sh[351]: PID TTY TIME CMD
[ 20.080050] testsuite-47.sh[351]: 342 ? 00:00:00 sleep
[ 20.082040] testsuite-47.sh[333]: + exit 42
```
When a command asks to load a unit directly and it is in state
UNIT_NOT_FOUND, and the cache is outdated, we refresh it and
attempto to load again.
Use the same logic when building up a transaction and a dependency in
UNIT_NOT_FOUND state is encountered.
Update the unit test to exercise this code path.
SIG-prefixed signals for `kill` are not POSIX compliant, so on Ubuntu CI
(which defaults to dash instead of bash) the TEST-52 contains following
error:
[ 9693.549638] sh[51]: + systemctl poweroff --no-block
[ 9693.553130] systemd-logind[26]: System is powering down.
[ 9693.608911] sh[54]: /bin/sh: 1: kill: Illegal option -S
This can be reproduced manually as well, either by running dash, or bash
in POSIX mode:
$ dash -c 'kill -SIGKILL 123'
dash: 1: kill: Illegal option -S
$ bash --posix -c 'kill -SIGKILL 123'
bash: line 0: kill: SIGKILL: invalid signal specification
When the system is under heavy load, it can happen that the unit cache
is refreshed for an unrelated reason (in the test I simulate this by
attempting to start a non-existing unit). The new unit is found and
accounted for in the cache, but it's ignored since we are loading
something else.
When we actually look for it, by attempting to start it, the cache is
up to date so no refresh happens, and starting fails although we have
it loaded in the cache.
When the unit state is set to UNIT_NOT_FOUND, mark the timestamp in
u->fragment_loadtime. Then when attempting to load again we can check
both if the cache itself needs a refresh, OR if it was refreshed AFTER
the last failed attempt that resulted in the state being
UNIT_NOT_FOUND.
Update the test so that this issue reproduces more often.
Prompted by systemd/systemd#16111.
* check if /var is a mountpoint - if not, something went wrong. In case
of systemd/systemd#16111 the /failed file was created, because
systemd-cryptsetup failed, but it ended up being empty, making the result
check incorrectly pass
* forward journal messages to console - if we fail to mount /var,
journald won't flush logs to the persistent storage and we end up
empty handed and with no clue what went wrong
For example, without systemd/systemd#16111 and with this patch:
...
[FAILED] Failed to start systemd-cryptsetup@varcrypt.service.
See 'systemctl status systemd-cryptsetup@varcrypt.service' for details.
[DEPEND] Dependency failed for cryptsetup.target.
...
[ 3.882451] systemd-cryptsetup[581]: Key file /etc/varkey is world-readable. This is not a good idea!
[ 3.883946] systemd-cryptsetup[581]: WARNING: Locking directory /run/cryptsetup is missing!
[ 3.884846] systemd-cryptsetup[581]: Failed to load Bitlocker superblock on device /dev/disk/by-uuid/180ba5ef-873b-4018-9968-47c23431f71a: Invalid argument
...
[ 4.099451] sh[606]: + mountpoint /var
[ 4.100025] sh[603]: + systemctl poweroff --no-block
[ 4.101636] systemd[1]: Finished systemd-user-sessions.service.
[ 4.102598] sh[608]: /var is not a mountpoint
[FAILED] Failed to start testsuite-02.service.
dm-verity support in dissect-image at the moment is restricted to GPT
volumes.
If the image a single-filesystem type without a partition table (eg: squashfs)
and a roothash/verity file are passed, set the verity flag and mark as
read-only.
Note that run_test() calls coredumpctl in a loop because in certain
environments (1 vCPU unaccelerated QEMU VM) it might take quite a
while to process the coredump.
