When checking the unit state after `systemctl freeze|thaw` we can be
"too fast" and get the intermediate state (freezing/thawing) which we're
not interested in. Let's wait a bit and try to get the state again in
such cases to avoid unnecessary flakiness.
```
[ 29.390203] testsuite-38.sh[218]: + state=thawing
[ 29.390203] testsuite-38.sh[218]: + '[' thawing = running ']'
[ 29.390203] testsuite-38.sh[218]: + echo 'error: unexpected freezer state, expected: running, actual: thawing'
[ 29.390203] testsuite-38.sh[218]: error: unexpected freezer state, expected: running, actual: thawing
[ 29.390203] testsuite-38.sh[218]: + exit 1
```
test-loop-block needs to run in qemu, so we are currently not
testing it in the CI. Run it by itself in a separate job from
TEST-02-UNITTESTS to avoid slowing that suite down.
Fixes https://github.com/systemd/systemd/issues/19966
Disable it in the bionic-* CI for now, as it's affected by
the same uevent ordering issue as TEST-50-DISSECT which makes
it flaky.
Fixes a bug introduced by cfea7618f2.
Before this commit:
mode=1777,size=10%,nr_inodes=400k,uid=496107520,gid=496107520,context=,sys.id:sys.role:systemd.nspawn.container.fs:s0,
After this commit:
mode=1777,size=10%,nr_inodes=400k,uid=496107520,gid=496107520,context=sys.id:sys.role:systemd.nspawn.container.fs:s0
Fixes#19976.
format_timestamp_relative currently returns the plural form of
years and months no matter the quantity, and in many cases (for
durations > 1 week) this is the same with days.
This patch changes this so that the function takes the quantity into account,
returning "1 month 1 week ago" instead of "1 months 1 weeks ago".
This is useful for provisioning initially empty secondary A/B root file
systems. We don't want those to ever be considered for automatic
mounting, for example in "systemd-nspawn --image=", hence we should
create them with the No-Auto flag turned on. Once a file system image is
dropped into the partition the flag may be turned off by the updater
tool, so that it is considered from then on.
Thew new option for this is called NoAuto. I dislike negated options
like this, but this is taken from the naming in the spec, which in turn
inherited the name from the same flag for Microsoft Data Partitions. To
minimize confusion, let's stick to the name hence.
The two are completely identical, only the return code is inverted.
let's hence make it easy for the compiler to make it the same function
call even in lowest optimization modes.
In many CI runs I noticed a race where we check the "active" state a bit
too early where the unit is still in the "inactive" state, causing the
`is-failed` check to fail. Mitigate this by waiting even if the unit is
in the inactive state and introduce a "safe net" which checks whether
the unit is not restarting indefinitely or more than it should (as
described in the original issue #3166).
Example:
```
[ 5.757784] testsuite-11.sh[216]: + systemctl --no-block start fail-on-restart.service
[ 5.853657] testsuite-11.sh[222]: ++ systemctl show --value --property ActiveState fail-on-restart.service
[ 5.946044] testsuite-11.sh[216]: + active_state=inactive
[ 5.946044] testsuite-11.sh[216]: + [[ inactive == \a\c\t\i\v\a\t\i\n\g ]]
[ 5.946044] testsuite-11.sh[216]: + [[ inactive == \a\c\t\i\v\e ]]
[ 5.946044] testsuite-11.sh[216]: + systemctl is-failed fail-on-restart.service
[ 5.946816] systemd[1]: fail-on-restart.service: Passing 0 fds to service
[ 5.946913] systemd[1]: fail-on-restart.service: About to execute false
[ 5.947011] systemd[1]: fail-on-restart.service: Forked false as 228
[ 5.947093] systemd[1]: fail-on-restart.service: Changed dead -> start
[ 5.947172] systemd[1]: Starting Fail on restart...
[ 5.947272] systemd[228]: fail-on-restart.service: Executing: false
[ 5.960553] testsuite-11.sh[227]: activating
[ 5.965188] testsuite-11.sh[216]: + exit 1
[ 6.011838] systemd[1]: Received SIGCHLD from PID 228 (4).
[ 6.012510] systemd[1]: fail-on-restart.service: Main process exited, code=exited, status=1/FAILURE
[ 6.012638] systemd[1]: fail-on-restart.service: Failed with result 'exit-code'.
[ 6.012834] systemd[1]: fail-on-restart.service: Service will restart (restart setting)
[ 6.012963] systemd[1]: fail-on-restart.service: Changed running -> failed
[ 6.013081] systemd[1]: fail-on-restart.service: Unit entered failed state.
```
Text currently refers to `/etc/nsswitch.conf` where it should refer to `/etc/resolv.conf`.
This is in the context of defining a nameserver IP and search domains.
The three-argument match() is a GNU AWK extension, thus breaking the
compatibility with mawk (used on Ubuntu/Debian, for example). Let's
replace it with a (hopefully) more portable sed expression to drop the
inadvertently introduced gawk dependency.
Fixes: #19957
Show message "Deactivated successfully" in debug mode (when manager is
user) rather than in info mode. This message has low information value
for regular users and it might be a bit overwhelming on a system with
a lot of devices.
The general idea with users and groups created through sysusers is that an
appropriate number is picked when the allocation is made. The number that is
selected will be different on each system based on the order of creation of
users, installed packages, etc. Since system users and groups are not shared
between installations, this generally is not an issue. But it becomes a problem
for initrd: some file systems are shared between the initrd and the host (/run
and /dev are probably the only ones that matter). If the allocations are
different in the host and the initrd, and files survive switch-root, they will
have wrong ownership.
This makes the gids build-time-configurable for all groups and users where
state may survive the switch from initrd to the host.
In particular, all "hardware access" groups are like this: files in /dev will
be owned by them. Eventually the new udev would change ownership, but there
would be a momemnt where the files were owned by the wrong group. The
allocations are "soft-static" in the language of Fedora packaging guidelines:
the uid/gid will be used if possible, but we'll fall back to a different
one. TTY_GID is the exception, because the number is used directly.
Similarly, the possibility to configure "soft-static" uids is added for daemons
which may usefully run in the initramfs: systemd-network (lease information and
interface state is serialized to /run), systemd-resolve (stub files and
interface state), systemd-timesync (/run/systemd/timesync).
Journal files are owned by the group systemd-journal, and acls are granted
for wheel and adm.
systemd-oom and systemd-coredump are excluded from this patch: I assume that
oomd is not useful in the initrd, and coredump leaves no state (it only creates
a pipe in /run?).
The defaults are not changed: if nothing is configured, dynamic allocation will
be used. I looked at a Debian system, and the numbers are all different than
on Fedora.
For Fedora, see the list of uids and gids at https://pagure.io/setup/blob/master/f/uidgid.
In particular, systemd-network and systemd-resolve got soft-static numbers to
make it easy to transition from a non-host-specific initrd to a host system
already a few years back (https://bugzilla.redhat.com/show_bug.cgi?id=1102002).
I also requested static allocations for sgx, input, render in
https://pagure.io/packaging-committee/issue/1078,
https://pagure.io/setup/pull-request/27.
Frantisek Sumsal
Zbigniew Jędrzejewski-Szmek
Yu Watanabe
Luca Boccassi
Luca Boccassi
Lennart Poettering
Anders Wenhaug
Jesse Stricker
plattrap
Jeremy Szu
Eric Cook
Jan Macku
Joerg Behrmann