v254 batch up to 92df356fe184fb5ddbe0b1276555271001c196db#478
Merged
bluca merged 48 commits intosystemd:v254-stablefrom May 18, 2025
Merged
v254 batch up to 92df356fe184fb5ddbe0b1276555271001c196db#478bluca merged 48 commits intosystemd:v254-stablefrom
bluca merged 48 commits intosystemd:v254-stablefrom
Conversation
For these objectives we ought to execve() at the end, i.e. if we ever hit the return path something went wrong in do_reexecute(). Let's properly report that via retval. (cherry picked from commit 590e0e3) (cherry picked from commit efcd9c6e62dbc66e5bc70046e8ad1df2ad97947f) (cherry picked from commit 1282484941ca8e65de1586f15fcb09ad897f20e0) (cherry picked from commit c82f2e6)
If a network mount returns EBUSY on umount, the logic introduced in 6dc68a0 causes shutdown to hang indefinitely on `fstatat()` (i.e., within `is_dir(m->path, true)`). Hence, skip this logic for network mounts (following the same motivation we use to skip read-only mounts in this kind of file systems). Fixes 6dc68a0 (cherry picked from commit cef2181) (cherry picked from commit 18dde3dd2aa8f05ecf950dab313efd5baf064625) (cherry picked from commit b7cb53a368fb998b9251e7c453d4e59a4d35a9d2) (cherry picked from commit 771f946)
So far /run/systemd/ was created as side-effect of initializing the D-Bus client/server. But in one of the next commits we'll suppress connecting to D-Bus in test runs, hence let's move the logic our of the D-Bus code and into manager_startup(). Then, also drop creating it again and again in PID 1 at various places, and just rely on it to exist. (cherry picked from commit e75fbee) (cherry picked from commit a4bb3316e0324c343a036a6fb87d57381af4b824) (cherry picked from commit d0c4baba4cff48415fae5f21d191e235279d9e21) (cherry picked from commit 61884a1)
This thing should not be "live", hence don't try to connect to the bus, or bind the private bus socket. Fixes: #36540 (cherry picked from commit 71a737d) (cherry picked from commit b4565a757f858ec3b45fe44574b2cd7dc8f7ac90) (cherry picked from commit 071fd1744e2f3302e54f0e96db2a7cf10c0963ba) (cherry picked from commit ad18087)
…[email protected] on s390x Path of the 3270 console in /sys is "/sys/class/tty/3270!tty1" but its device node is "/dev/3270/tty1". (cherry picked from commit dbe61d9) (cherry picked from commit 23dc4450cddd5ee89d291600e226a3615b56a185) (cherry picked from commit 7b4d672e07747b1dd7f596248fc479088e4485ad) (cherry picked from commit 26bcf28)
We didn't check the number of arguments first, hence ended up outputting some ugly complaints with `(null)` in a format string. And what's worse accepted any number of arguments, where we'd ignore all but the first two though. (cherry picked from commit e5dfe2c) (cherry picked from commit 81b821d08ceb5feec4b879d59c194897a957eb5e) (cherry picked from commit 3fc144d45c37bddc930858953aeafb2062fe73c7) (cherry picked from commit cafcfa7)
Don't shortcut if we don't have the necessary environment variables set in sd_bus_open_user_machine(). (cherry picked from commit 9e34c34) (cherry picked from commit bd06aa555603f877774942dcda4664e8e44f21fd) (cherry picked from commit 71cca3e39c63038ace72be1cb3955a5546caf607) (cherry picked from commit 9ab7f14)
…m empty notification queue A unit might be pending in the empty queue still when we add a PID to the cgroup. At that point, let's explicitly remove the unit from that queue. Fixes: #36781 (cherry picked from commit bb16097) (cherry picked from commit 13b011f0e84bd30d524a10e0dd839b508b8e0011) (cherry picked from commit c834d98ddfb568a26ee4920b7431d384cbcbb069) (cherry picked from commit cc0764c)
It is not necessary to clear previous keymap assignment, as `localectl set-keymap` will anyway overwrite the previous assignment. This drops the unnecessary restart of systemd-localed in the loop. The mkosi test image contains about 500~700 keymaps. The test performance is greatly improved by reducing the number of restarts, especially when the test is running with sanitizers. On Fedora 41 with sanitizers, Before: 1/1 systemd:integration-tests / TEST-73-LOCALE OK 1157.50s After: 1/1 systemd:integration-tests / TEST-73-LOCALE OK 104.43s (cherry picked from commit d8a3535) (cherry picked from commit 614a284f472c0f162f1ea93092c1b03646138f0b) (cherry picked from commit 593df05716174359dfc2d861fabed6e304974a1e) (cherry picked from commit 7aa1a97)
This changed in e3e6f99. Closes systemd/systemd#36761. (cherry picked from commit 4dd94e5) (cherry picked from commit 65b3d7f08a8ecf66164eaafba9e467e558e4cf59) (cherry picked from commit faa5d159df0b19ff03fcf6928a80a2e4d01011ae) (cherry picked from commit b4f1920)
…rent/child functions The test "hangs" and times out on some arm64 machines. It actually works as expected, but the machine has 2016 children under /sys/devices/system/memory/, and the tests do a double loop over this, which is slow enough to hit the 120 s limit. Add a limit on the number of iterations. Another option would be to exclude "memory" subsystem. But we may have other subsystems which have the same problem in the future, so I think it'll be more robust to not try to limit the fix to a specific subsystem. (cherry picked from commit 74cb65e) (cherry picked from commit e35435b0a11e6c61c8c43b0cf8dc65a563b4a670) (cherry picked from commit 1f71726206006ff18ea0f96b109faff37dcc48f2) (cherry picked from commit d05d968)
bind9 9.21 removed the deprecated 'managed-keys', swap it with 'trust-anchors' if the version is 9.21 or newer [ 20.654086] TEST-75-RESOLVED.sh[1217]: + delv -a /etc/bind.keys @ns1.unsigned.test signed.test [ 20.654425] TEST-75-RESOLVED.sh[1218]: + tee /tmp/tmp.D4LNomAKqY [ 20.672599] TEST-75-RESOLVED.sh[1218]: ;; /etc/bind.keys:1: option 'managed-keys' no longer exists (cherry picked from commit 5f8e529) (cherry picked from commit 85df0981b27c59649fa75916ba1efb4fe820a4dd) (cherry picked from commit 80d4bc9577d8f3fda68e3eb25d4dba8cb8ba47f0) (cherry picked from commit 80d9d37)
Fixes a bug introduced by 55365b0 (v254). The arguments `(rd.)systemd.mount-extra` take a value that looks like `WHAT:WHERE[:FSTYPE[:OPTIONS]]`. The `OPTIONS` were parsed into a nulstr where a comma-separated c-string was expected. This leads to a bug where only the first option was taken into account by the generator. For example, if you passed `systemd.mount-extra=/x:/y:baz:ro,defaults` to the kernel, `systemd-fstab-generator` would translate that into a nulstr: `ro\0defaults\0`. Since methods processing options in the generator expected a comma-separated c-string, they would only see the first option, `ro` in this case. (cherry picked from commit 06fadc4) (cherry picked from commit 0122eae1af270baed63b258852fa26396ea00fc8) (cherry picked from commit d255dc77811ad91965100aa4e59093e577ed056b) (cherry picked from commit c19df38)
When trying to calculate the next firing of 'hourly', we'd lose the
tm_isdst value on the next iteration.
On most systems in Europe/Dublin it would cause a 100% cpu hang due to
timers restarting.
This happens in Europe/Dublin because Ireland defines the Irish Standard Time
as UTC+1, so winter time is encoded in tzdata as negative 1 hour of daylight
saving.
Before this patch:
$ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly'
Original form: hourly
Normalized form: *-*-* *:00:00
Next elapse: Sat 2025-03-29 23:00:00 GMT
(in UTC): Sat 2025-03-29 23:00:00 UTC
From now: 13h ago
Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT
(in UTC): Sun 2025-03-30 00:00:00 UTC
From now: 12h ago
Iteration systemd#3: Sun 2025-03-30 00:00:00 GMT <-- note every next iteration having the same firing time
(in UTC): Sun 2025-03-30 00:00:00 UTC
From now: 12h ago
...
With this patch:
$ env TZ=IST-1GMT-0,M10.5.0/1,M3.5.0/1 systemd-analyze calendar --base-time='Sat 2025-03-29 22:00:00 UTC' --iterations=5 'hourly'
Original form: hourly
Normalized form: *-*-* *:00:00
Next elapse: Sat 2025-03-29 23:00:00 GMT
(in UTC): Sat 2025-03-29 23:00:00 UTC
From now: 13h ago
Iteration systemd#2: Sun 2025-03-30 00:00:00 GMT
(in UTC): Sun 2025-03-30 00:00:00 UTC
From now: 12h ago
Iteration systemd#3: Sun 2025-03-30 02:00:00 IST <-- the expected 1 hour jump
(in UTC): Sun 2025-03-30 01:00:00 UTC
From now: 11h ago
...
This bug isn't reproduced on Debian and Ubuntu because they mitigate it by
using the rearguard version of tzdata. ArchLinux and NixOS don't, so it would
cause pid1 to spin during DST transition.
This is how the affected tzdata looks like:
$ zdump -V -c 2024,2025 Europe/Dublin
Europe/Dublin Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=1 gmtoff=0
Europe/Dublin Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 IST isdst=0 gmtoff=3600
Europe/Dublin Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 IST isdst=0 gmtoff=3600
Europe/Dublin Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=1 gmtoff=0
Compare it to Europe/London:
$ zdump -V -c 2024,2025 Europe/London
Europe/London Sun Mar 31 00:59:59 2024 UT = Sun Mar 31 00:59:59 2024 GMT isdst=0 gmtoff=0
Europe/London Sun Mar 31 01:00:00 2024 UT = Sun Mar 31 02:00:00 2024 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 27 00:59:59 2024 UT = Sun Oct 27 01:59:59 2024 BST isdst=1 gmtoff=3600
Europe/London Sun Oct 27 01:00:00 2024 UT = Sun Oct 27 01:00:00 2024 GMT isdst=0 gmtoff=0
Fixes #32039.
(cherry picked from commit e4bb033)
(cherry picked from commit 07c01efc82d4a239ef0d14da54d36053294ad203)
There were some conflicts related to the skipping of
6f5cf41, but the tests pass with and the
example output above also looks good, so I think the backport is correct.
(cherry picked from commit 1568dea89ebb84ed2c9cf8c45aaf90c07858cbc0)
(cherry picked from commit f3dc34e)
Let's gracefully handle cases where a device disappears in the time we between our discovery and when we want to detach it, due to "auto-clear" or a similar logic. The loopback case already handled this quite OK, do the same for MD and swap too. Switch to ERRNO_IS_DEVICE_ABSENT() for all checks, just in case. Also improve debug logging for all these cases, so we know exactly what is going on. This is inspired by #37160, but shouldn't really fix anything there, I am pretty sure the ENODEV seen in that output stems from the STOP_ARRAY call, not from the open(). Note that this does not change anything for the device mapper case, because the DM subsystem does not return useful error codes to userspace, hence everything is a complete mess there. (cherry picked from commit 2791b2b) (cherry picked from commit 4f0a4976dfe64399bc5a3c6b8f00675e2548b067) (cherry picked from commit fc1d80f5b31f629ee03cfd0c0cabaa67aa646dd8) (cherry picked from commit 9ffa0a5)
The functions `sd_bus_emit_interfaces_added_strv`, `sd_bus_emit_interfaces_removed_strv` and `sd_bus_emit_properties_changed_strv` take an `char **` not `const char **` as last argument. See `src/systemd/sd-bus.h` for the function definition. (cherry picked from commit 3f75684) (cherry picked from commit 196a1c3ccb81033e1b54076ba984bfbbbe0dd9de) (cherry picked from commit 62a63713776037a1e054be1c7bd4aa1e7de4fa3d) (cherry picked from commit 26ef8b8)
The previous commit removed the UINT_MAX check for the fd array. Let's now re-add one, but at a better place, and with a more useful limit. As it turns out the kernel does not allow passing more than 253 fds at the same time, hence use that as limit. And do so immediately before calculating the control buffer size, so that we catch multiplication overflows. (cherry picked from commit cb42df5) (cherry picked from commit 3fe78b02280d11746afc979dfed561dbc3fc2554) (cherry picked from commit 67347ca)
…arlink message 253 is the max number of fds one can send at once on a Linux AF_UNIX socket. Hence refuse to send more early. (cherry picked from commit 92c52a9) (cherry picked from commit d80f2b149cb282c9a0737a6cdf847be2ee81bfeb) (cherry picked from commit 9916985d8dc9d725aa2855327a49649e405deb7d) (cherry picked from commit 27719eb)
Document effect of the SR-IOV section in .link vs .network files and restructure the SR-IOV section introduction for clarity. (cherry picked from commit 8e24558) (cherry picked from commit 3a668aae1398762438b9ffee75622e552f9d7f11) (cherry picked from commit f930bd1c74cc49dacf6d99e2ec4eff550f92d0ca) (cherry picked from commit 21a0539)
Otherwise passing invalid data means asserts get hit instead of handling it gracefully. Other verbs already do the same checks. busctl get-property org.freedesktop.systemd1 '*' org.freedesktop.systemd1.Manager Version Assertion 'object_path_is_valid(path)' failed at src/libsystemd/sd-bus/bus-message.c:562, function sd_bus_message_new_method_call(). Aborting. Aborted (core dumped) (cherry picked from commit b16e6fd) (cherry picked from commit 6961d8ac6e0cc8d81c20c7de07595834ffabd556) (cherry picked from commit da7c0fc714a015dd9d7e8c1d622aa10f2f016111) (cherry picked from commit e26ba16)
Document .link .network and .netdev file type distinctions in early introductory text, and document distro-specific need to sync link files with early-boot copies, see Debian bug 1005282: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005282 for an example. (cherry picked from commit a50fa2a) (cherry picked from commit 1f654739f8a05110b68461cf483d5c07b2ef7723) (cherry picked from commit 1e96e999377b03e052a0379223e40255aa767df8) (cherry picked from commit 798a835)
Currently, Fedora's systemd RPM doesn't own systemenvgeneratordir (ie., /usr/lib/systemd/system-environment-generators) [1] because it's not created when systemd is installed. In contrast, userenvgeneratordir (ie., /usr/lib/systemd/user-environment-generators) is created, unless the environment-d Meson option is explicitly disabled. While this can be worked around elsewhere, it's better if the upstream build system created the directories consistently. It will avoid repetition, and prevent silly bugs or deviations from creeping in. [1] https://bugzilla.redhat.com/show_bug.cgi?id=2284085 (cherry picked from commit ab46feb) (cherry picked from commit bd27edd3de9b3b30f7225994a799e46fba930568) (cherry picked from commit f38abc546d09f99eb011b2bfe8605ac7259baf02) (cherry picked from commit 03e38fb)
On Linux, read() on a message queue descriptor returns the message queue statistics, not the actual message queue data. We need to use mq_receive() to drain the queues instead. Fixes a problem where a POSIX message queue socket unit with messages in the queue at shutdown time could result in a hang on reboot/shutdown. (cherry picked from commit ffb6adb) (cherry picked from commit 4ab235b029f2107ed53f6580a7b57a48b63b4035) (cherry picked from commit 5ac9982bda6429bceb64358f84f5174d4dd0a1b8) (cherry picked from commit c1581f6)
…nt` (#37409) Co-authored-by: Eisuke Kawashima <[email protected]> (cherry picked from commit 6d07d23) (cherry picked from commit 11c16d414ebbcb13e39971d90ece4a1e0db183d2) (cherry picked from commit 003a0bb9e3bfef9ab99ce409ea08d6fb544440d0) (cherry picked from commit bd47958)
The existing description was not *wrong*, but it was a bit muddled. Let's reorder the text to give a short intro and then describe what the options actually do and the clear "true" and "false" cases first, and then describe autodetection. Related to https://yeswehack.com/vulnerability-center/reports/346802. (cherry picked from commit 718dbdb) (cherry picked from commit d8659058f40186f07799bc2a8e624aece33412ac) (cherry picked from commit f75ad1137ef43bb7a65fd598c807945476631411) (cherry picked from commit 5212152)
$PAGER wasn't documented, but actually we treat it same as $SYSTEMD_PAGER, except for lower priority. And the two variables can be used to disable the pager, even if $SYSTEMD_PAGERSECURE is not set. Behaviour is (obviously) not changed by this patch, it intentionally just updates the docs to match the code. (cherry picked from commit b6b7817) (cherry picked from commit affb45d6b2dfdb3a87da2e0241be8c5c5c9a9d8f) (cherry picked from commit ab19d19d3e89a270e40b9b9cff845581d3d9e3a4) (cherry picked from commit 946f7b7)
This returns to the original approach proposed in systemd/systemd#17270. After review, the approach was changed to use sd_pid_get_owner_uid() instead. Back then, when running in a typical graphical session, sd_pid_get_owner_uid() would usually return the user UID, and when running under sudo, geteuid() would return 0, so we'd trigger the secure path. sudo may allocate a new session if is invoked outside of a session (depending on the PAM config). Since nowadays desktop environments usually start the user shell through user units, the typical shell in a terminal emulator is not part of a session, and when sudo is invoked, a new session is allocated, and sd_pid_get_owner_uid() returns 0 too. Technically, the code still works as documented in the man page, but in the common case, it doesn't do the expected thing. $ build/test-sd-login |& rg 'get_(owner_uid|cgroup|session)' sd_pid_get_session(0) → No data available sd_pid_get_owner_uid(0) → 1000 sd_pid_get_cgroup(0) → /user.slice/user-1000.slice/[email protected]/app.slice/app-ghostty-transient-5088.scope/surfaces/556FAF50BA40.scope $ sudo build/test-sd-login |& rg 'get_(owner_uid|cgroup|session)' sd_pid_get_session(0) → c289 sd_pid_get_owner_uid(0) → 0 sd_pid_get_cgroup(0) → /user.slice/user-0.slice/session-c289.scope I think it's worth checking for sudo because it is a common case used by users. There obviously are other mechanims, so the man page is extended to say that only some common mechanisms are supported, and to (again) recommend setting SYSTEMD_LESSSECURE explicitly. The other option would be to set "secure mode" by default. But this would create an inconvenience for users doing the right thing, running systemctl and other tools directly, because then they can't run privileged commands from the pager, e.g. to save the output to a file. (Or the user would need to explicitly set SYSTEMD_LESSSECURE. One option would be to set it always in the environment and to rely on sudo and other tools stripping it from the environment before running privileged code. But that is also fairly fragile and it obviously relies on the user doing a complicated setup to support a fairly common use case. I think this decreases usability of the system quite a bit. I don't think we should build solutions that work in priniciple, but are painfully inconvenient in common cases.) Fixes https://yeswehack.com/vulnerability-center/reports/346802. Also see polkit-org/polkit#562, which adds support for $SUDO_UID/$SUDO_GID to pkexec. (cherry picked from commit cd93478) (cherry picked from commit b93f53c122124582fa80ae246343791063d65074) (cherry picked from commit f3a13eca4ed6b4852153179a2197ee797bbbe898) (cherry picked from commit df9bf67)
The tools from main are no longer compatible with images built in this stable branch. Ubuntu 24.04 ships with v255 which is good enough, so restore those binaries. (cherry picked from commit 92df356)
|
We were not able to find or create Copr project Unless the HTTP status code above is >= 500, please check your configuration for:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
18 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
No description provided.