When booting Linux with ACPI in QEMU, the device tree is not used and
the DT based detection will not work. DMI values are accurate though
and indicate QEMU.
While detect_vm_dmi_vendor() was enabled for RISC-V in a previous commit,
it missed detect_vm_dmi(), so it was never actually used. Fix that.
Signed-off-by: Fabian Vogt <fvogt@suse.de>
Otherwise, the scope that the nspawn container belonging to may be
removed before the grandchild process of the machined exits and it may
be SIGKILLed.
```
[ 100.829613] systemd-machined[678]: Successfully forked off '(sd-bindmnt)' as PID 2962.
[ 100.833366] systemd-nspawn[2953]: Inner child finished, invoking payload.
[ 100.836111] (sd-bindmnt)[2962]: Skipping PR_SET_MM, as we don't have privileges.
[ 100.836401] (sd-bindmnt)[2962]: Successfully forked off '(sd-bindmnt-inner)' as PID 2964.
[ 100.846498] (sd-bindmnt)[2962]: (sd-bindmnt-inner) terminated by signal KILL.
[ 100.848846] systemd[1]: machine-TEST\x2d13\x2dNSPAWN.machinectl\x2dbind.7ye.scope: cgroup is empty
[ 100.849303] systemd[1]: machine-TEST\x2d13\x2dNSPAWN.machinectl\x2dbind.7ye.scope: Deactivated successfully.
[ 100.849317] systemd[1]: machine-TEST\x2d13\x2dNSPAWN.machinectl\x2dbind.7ye.scope: Changed running -> dead
[ 100.849752] systemd[1]: machine-TEST\x2d13\x2dNSPAWN.machinectl\x2dbind.7ye.scope: Consumed 91ms CPU time, 1.3M memory peak.
[ 100.850399] systemd-machined[678]: (sd-bindmnt) failed with exit status 1.
[ 100.850414] systemd-machined[678]: Child failed.
[ 100.854574] systemd-machined[678]: Failed to mount /tmp/marker-varlink on /tmp/marker-varlink in the namespace of machine 'TEST-13-NSPAWN.machinectl-bind.7ye': Protocol error
```
Hopefully fixes#38434.
Fixes the following build warning:
```
In file included from ../../../home/runner/work/systemd/systemd/src/basic/assert-util.h:4,
from ../../../home/runner/work/systemd/systemd/src/basic/forward.h:17,
from ../../../home/runner/work/systemd/systemd/src/basic/filesystems.h:4,
from src/basic/filesystem-sets.c:2:
src/basic/filesystem-sets.c: In function ‘fs_in_group’:
../../../home/runner/work/systemd/systemd/src/fundamental/assert-fundamental.h:76:9: warning: array subscript 42 is above array bounds of ‘const char[28]’ [-Warray-bounds=]
76 | log_assert_failed_unreachable(PROJECT_FILE, __LINE__, __func__)
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/basic/filesystem-sets.c:559:18: note: in expansion of macro ‘assert_not_reached’
559 | default: assert_not_reached();
| ^~~~~~~~~~~~~~~~~~
```
Follow-up for aca4353ab2.
Similar to fc4a9c9ce6.
It is not easy to understand what happens to a journal file
even with debug logs enabled. Add more dbg messages around operations
started by users to make it possible to follow the flow of operations.
Asus ROG keyboards seems to send power off key code when keyboard wake
up. Reserve the key codes could suppress this problem.
Devices added: ROG Falchion & ROG Scope
Based on the work by Jon Nettleton:
https://gist.github.com/jnettlet/afb20a048b8720f3b4eb8506d8b05643
- drop unused variables,
- adjust number of partitions, interations, and timeout,
- clear partitions on each test case finished,
- check if unnecessary devlinks are removed,
- several coding style cleanups.
To suppress the following warnings in case check_device_unit() failed e.g.
when the device is already removed:
```
sed: couldn't write 130 items to stdout: Broken pipe
awk: write failure (Broken pipe)
awk: close failed on file "/dev/stdout" (Broken pipe)
```
If the removal of the devlink is requested due to this is a 'remove' event,
it is trivial that the devlink will not be owned by this device anymore.
Let's read the devlink and if it points to our device node, then we need
to update the devlink. If it points to another device node, then it is already
owned by another device, hence we should not touch it and keep it as is.
Fixes#37823.
Fix regression introduced in a7bfb9f76b,
where busy loop can be started with a request for following logs with a
range header set with num_skip value pointing beyond the end of the
journal. In that case the reader callback returns 0 and is called
immediately again, usually causing an endless loop that is not recovered
even when new journal events are added.
The bug does not occur if num_skip is not set - in that case if no
journal entries matching the filters are added, the tight loop is
avoided by the sd_journal_wait().
To fix the issue, when no matching journal events are available, set a
flag and reuse the backoff mechanism using the sd_journal_wait().
Link: https://github.com/home-assistant/operating-system/issues/4190
It seems the failing test in https://github.com/systemd/systemd/issues/37626
is due to MONOTONIC_USEC= being somehow lost. Add a trailing newline when
sending messages with socat, hopefully ensuring it is delivered and read.
As prompted by #38393, search domains may be large when a complicated
network setting is used, especially when VPN is used. Let's bump the
limit to 1024.
Note, this does not bump the maximum number of DNS servers, as setting
thousands of DNS servers is spurious and mostly meaningless. Let's keep
the maximum for a while until someone requests to also bump them.
Continuation of b950ee06e6.
Closes#38393.
- move to TEST-07-PID1, as it is a timer setting,
- rename the timer and service, to emphasize they are for testing
DeferReactivation=,
- use timeout command to wait for the timer being triggered several times,
- stop the timer when not necessary,
- accept 9 seconds as delta, as there are fluctuations.
Fixes the following failure:
```
TEST-74-AUX-UTILS.sh[422]: + last=
TEST-74-AUX-UTILS.sh[422]: + read -r time
TEST-74-AUX-UTILS.sh[422]: + '[' -n '' ']'
TEST-74-AUX-UTILS.sh[422]: + last=1753779616
TEST-74-AUX-UTILS.sh[422]: + read -r time
TEST-74-AUX-UTILS.sh[422]: + '[' -n 1753779616 ']'
TEST-74-AUX-UTILS.sh[422]: + delta=9
TEST-74-AUX-UTILS.sh[422]: + '[' 9 -lt 10 ']'
TEST-74-AUX-UTILS.sh[422]: + echo 'Timer fired too early: 9 < 10'
```
Fixes#38403.
As discussed in https://github.com/systemd/systemd/issues/38399, "ordinary"
systems can have the field table with a large number of values, causing journal
rotation to occur early. For example, audit generates a log of fields:
$ journalctl --fields | rg -c '^_?AUDIT'
114
It seems that the "structured log" capabilities of the journal are being use
more than in the past. Looking at some journal files on my system, it seems
the field hash table field is quite high in many cases:
$ build/test-journal-dump /var/log/journal/*/* | rg 'table fill'
Data hash table fill: 15.1%
Field hash table fill: 69.1%
Data hash table fill: 4.9%
Field hash table fill: 32.4%
Data hash table fill: 10.2%
Field hash table fill: 34.2%
Data hash table fill: 9.9%
Field hash table fill: 37.2%
Data hash table fill: 26.8%
Field hash table fill: 21.9%
Data hash table fill: 35.6%
Field hash table fill: 22.8%
Data hash table fill: 25.5%
Field hash table fill: 54.1%
Data hash table fill: 3.4%
Field hash table fill: 43.8%
Data hash table fill: 75.0%
Field hash table fill: 70.3%
Data hash table fill: 75.0%
Field hash table fill: 63.1%
Data hash table fill: 75.0%
Field hash table fill: 74.2%
Data hash table fill: 35.6%
Field hash table fill: 43.2%
Data hash table fill: 35.5%
Field hash table fill: 75.4%
Data hash table fill: 75.0%
Field hash table fill: 59.8%
Data hash table fill: 75.0%
Field hash table fill: 56.5%
Data hash table fill: 16.9%
Field hash table fill: 76.3%
Data hash table fill: 18.1%
Field hash table fill: 76.9%
Data hash table fill: 75.0%
Field hash table fill: 42.0%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 32.1%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 22.8%
Data hash table fill: 75.0%
Field hash table fill: 21.9%
Data hash table fill: 75.0%
Field hash table fill: 22.5%
Data hash table fill: 9.6%
Field hash table fill: 53.8%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 35.6%
Field hash table fill: 75.1%
Data hash table fill: 33.6%
Field hash table fill: 50.2%
Data hash table fill: 75.0%
Field hash table fill: 26.7%
Data hash table fill: 75.0%
Field hash table fill: 25.8%
Data hash table fill: 75.0%
Field hash table fill: 29.1%
Data hash table fill: 75.0%
Field hash table fill: 25.8%
Data hash table fill: 75.0%
Field hash table fill: 31.8%
Data hash table fill: 75.0%
Field hash table fill: 18.9%
Data hash table fill: 75.0%
Field hash table fill: 22.2%
Data hash table fill: 75.0%
Field hash table fill: 20.1%
Data hash table fill: 75.0%
Field hash table fill: 29.1%
Data hash table fill: 75.0%
Field hash table fill: 30.9%
Data hash table fill: 75.0%
Field hash table fill: 28.5%
Data hash table fill: 75.0%
Field hash table fill: 28.5%
Data hash table fill: 75.0%
Field hash table fill: 25.8%
Data hash table fill: 75.0%
Field hash table fill: 25.2%
Data hash table fill: 75.0%
Field hash table fill: 39.3%
Data hash table fill: 50.2%
Field hash table fill: 75.1%
Data hash table fill: 75.0%
Field hash table fill: 61.9%
Data hash table fill: 75.0%
Field hash table fill: 56.5%
Data hash table fill: 75.0%
Field hash table fill: 58.6%
Data hash table fill: 48.9%
Field hash table fill: 79.6%
Data hash table fill: 75.0%
Field hash table fill: 71.5%
Data hash table fill: 75.0%
Field hash table fill: 60.1%
Data hash table fill: 31.4%
Field hash table fill: 75.7%
Data hash table fill: 27.0%
Field hash table fill: 69.4%
Data hash table fill: 28.9%
Field hash table fill: 76.6%
Data hash table fill: 60.2%
Field hash table fill: 79.9%
Data hash table fill: 8.8%
Field hash table fill: 78.7%
Data hash table fill: 5.8%
Field hash table fill: 61.3%
Data hash table fill: 75.0%
Field hash table fill: 64.0%
Data hash table fill: 61.4%
Field hash table fill: 63.4%
Data hash table fill: 29.7%
Field hash table fill: 61.9%
Data hash table fill: 18.9%
Field hash table fill: 30.9%
Data hash table fill: 1.4%
Field hash table fill: 22.2%
Data hash table fill: 0.4%
Field hash table fill: 13.5%
Data hash table fill: 2.6%
Field hash table fill: 37.5%
Data hash table fill: 1.3%
Field hash table fill: 23.4%
Data hash table fill: 0.6%
Field hash table fill: 15.3%
Data hash table fill: 18.7%
Field hash table fill: 33.9%
Data hash table fill: 7.4%
Field hash table fill: 37.5%
Data hash table fill: 20.2%
Field hash table fill: 44.1%
Data hash table fill: 1.3%
Field hash table fill: 33.0%
Data hash table fill: 75.0%
Field hash table fill: 19.2%
Data hash table fill: 42.2%
Field hash table fill: 23.4%
Data hash table fill: 1.6%
Field hash table fill: 87.1%
Data hash table fill: 0.1%
Field hash table fill: 98.8%
Data hash table fill: 0.2%
Field hash table fill: 128.8%
Data hash table fill: 15.4%
Field hash table fill: 31.2%
Data hash table fill: 7.4%
Field hash table fill: 22.5%
Data hash table fill: 10.5%
Field hash table fill: 38.7%
Data hash table fill: 2.8%
Field hash table fill: 18.0%
Data hash table fill: 1.5%
Field hash table fill: 15.9%
Data hash table fill: 0.0%
Field hash table fill: 7.5%
Data hash table fill: 0.1%
Field hash table fill: 12.0%
Data hash table fill: 0.2%
Field hash table fill: 10.8%
Data hash table fill: 0.2%
Field hash table fill: 15.6%
Data hash table fill: 0.1%
Field hash table fill: 11.7%
Data hash table fill: 0.1%
Field hash table fill: 12.0%
Data hash table fill: 0.0%
Field hash table fill: 6.6%
Data hash table fill: 1.4%
Field hash table fill: 18.0%
Data hash table fill: 0.7%
Field hash table fill: 16.8%
Data hash table fill: 1.1%
Field hash table fill: 18.0%
Data hash table fill: 0.2%
Field hash table fill: 10.8%
Data hash table fill: 0.1%
Field hash table fill: 10.8%
Data hash table fill: 0.4%
Field hash table fill: 11.1%
Since filling of the field hash table to 75% normally causes file rotation,
let's double the default to make rotation happen less often.
We'll use 11kB more for the hash table, which should be fine, considering
that journal files are usually at least 8 MB.
Closes https://github.com/systemd/systemd/issues/38399.
It's easier to think about the size in "objects", not bytes. Let's convert to
bytes at the last moment.
Also drop some of the pointless size suffixes. In general, it's the size of the
variable that matters, not the constant that is written to it.
No functional change.
This fixes Acer Nitro ANV15-51 Nitro sense toggle
Event: time 1753852156.475850, -------------- SYN_REPORT ------------
Event: time 1753852156.565054, type 4 (EV_MSC), code 4 (MSC_SCAN), value f5
Event: time 1753852156.565054, type 1 (EV_KEY), code 148 (KEY_PROG1), value 0
The CI run is failing in the stop command:
```
[ 4841.936906] TEST-71-HOSTNAME.sh[140]: + stop_hostnamed
[ 4841.936906] TEST-71-HOSTNAME.sh[140]: + systemctl stop systemd-hostnamed.service
[ 4845.959747] TEST-71-HOSTNAME.sh[226]: Job for systemd-hostnamed.service canceled.
[ 4846.013286] systemd[1]: TEST-71-HOSTNAME.service: Main process exited, code=exited, status=1/FAILURE
[ 4846.013792] systemd[1]: TEST-71-HOSTNAME.service: Failed with result 'exit-code'.
[ 4846.021821] systemd[1]: Failed to start TEST-71-HOSTNAME.service - TEST-71-HOSTNAME.
```
This happens when we create the stop job, but while we're waiting for
it to finish, something triggers a start of the unit and we lose to competing
start job.
Hopefully fixes#36089.
drained() checks PTYForward.master_readable flag, but it may be
tentatively unset due to a tentative error like EAGAIN in the previous
IO event. Let's try to call shovel() one more time, which re-read the
master and call drained() at the end. Otherwise, we may lost some data.
When PTYForward.done is set, the PTYForward.master is already
disconnected. Let's not try to read the already closed file descriptor.
Also, if we previously received vhangup, then it is not necessary to
re-read the device to check vhangup, as we already know.
This also make the check slightly delayed, and use a defer event source,
to make the function can be called safely in another event source.
Currently, pty_forward_set_ignore_vhangup() is only used for disabling
the flag. To make the function also disable PTY_FORWARD_IGNORE_INITIAL_VHANGUP
flag, this renames it to pty_forward_honor_vhangup().
Also, for consistency, pty_forward_get_ignore_vhangup() and
ignore_vhangup() are replaced with pty_forward_vhangup_honored().
Previously, do_shovel() sometimes call pty_forward_done(), and
its caller shovel() also call pty_forward_done(). Let's move all
pty_forward_done() calls to shovel(), and do_shovel() not call it.
No functional change, just refactoring.
We had errno_to_name() which works for "known" errnos, and returns NULL for
unknown ones, and then ERRNO_NAME which always returns an answer, possibly just
a number as a string, but requires a helper buffer.
It is possible for the kernel to add a new errno. We recently learned that some
architectures define custom errno names. Or for some function to unexpectedly
return a bogus errno value. In almost all cases it's better to print that value
rather than "n/a" or "(null)". So let's use ERRNO_NAME is most error handling
code. Noteably, our code wasn't very good in handling the potential NULL, so
in various places we could print "(null)". Since this is supposed to be used
most of the time, let's shorten the names to ERRNO_NAME/errno_name.
There are a few places where we don't want to use the fallback path, in
particular for D-Bus error names or when saving the error name. Let's rename
errno_to_name() to errno_name_no_fallback() to make the distinction clearer.
Follow-up for cfb7abc7fc
For whatever reason, ly is setting $XDG_RUNTIME_DIR before invoking
PAM session on its own
(https://github.com/fairyglade/ly/blob/v1.1.1/src/auth.zig#L45),
which after the offending commit will potentially be unset again
by pam_systemd. Let's restore the previous behavior if not switching area.
Fixes#38402
Graham Clinch
Fabian Vogt
Yu Watanabe
Luca Boccassi
Luca Boccassi
RocketDev
Jan Čermák
ssoss
Zbigniew Jędrzejewski-Szmek
SoloSaravanan
Jesse Guo
Emir SARI
Luna Jernberg
Ivan Kruglov
DaanDeMeyer
Mike Yuan