In multi-seat scenarios, a display manager might need to start multiple
greeter sessions. But systemd allows at most one graphical session per
user. So, display managers now have a range of UIDs to dynamically
allocate users for their greeter sessions.
Note that this doesn't care which partition set (A or B in an A/B
scenario) is actually newer, it just picks the first suitable, but
that's something we should look into later. For now, let's just make
verity sig partitions work the same way as verity partitions.
Fixes#34835
We already do this for partition_min_size(), let's do it for
partition_max_size() as well. This makes sure repart doesn't accidentally
try to grow verity sig partitions to larger sizes than the hardcoded
max size in systemd.
If .attr_set is zero (and .att_clr, .propagation too), then there's no
point in calling mount_setattr().
Fixes: #37062
Note that this optimization is not precisely load-bearing anymore, since
3cc23a2c23 got merged which removes the
only caller of make_fsmount() that might trigger it. But it's worth
fixing generic code anyway, in case it gets used like this later again.
When bootctl is called by an unprivileged user, then previously we got
```
Failed to read "/boot/EFI/systemd": Permission denied
Failed to open '/boot//loader/loader.conf': Permission denied
```
Now, with this patch, we get
```
Failed to read "/boot/EFI/systemd": Permission denied
Failed to open '/boot/loader/loader.conf': Permission denied
```
A new core was added to the test, but the loop counter was not increased
to wait for it, so the test races against systemd-coredump's processing.
This failed at least once in debci:
8015s [ 32.227813] TEST-87-AUX-UTILS-VM.sh[1038]: + coredumpctl info COREDUMP_TIMESTAMP=1679509902000000
8015s [ 32.228684] TEST-87-AUX-UTILS-VM.sh[1723]: No coredumps found.
Follow-up for 0c49e0049b
Fixes https://github.com/systemd/systemd/issues/37666
Follow-up for 728dbaeffb
and ad6ca4a612
This is inspired by #37538, see the discussion in
https://github.com/systemd/systemd/pull/37538#discussion_r2110229075.
If the user already specifies $TERM (which is actually
quite common if you look at run0), we'd needlessly invoke
the "fallback" logic and
a) possibly issue a DCS query whose result we end up simply
discarding in strv_env_merge()
b) set $COLORTERM to "truecolor" unconditionally, whereas
the explicit $TERM value might intend to disable the color output
To address this, the logic of setting fallback $TERM and friends
has been split out of build_environment(), and we'd call into it
only after all envvars have been collected.
This code seems to work quickly and nicely for a bunch of modern
terminals. Setting $TERM automatically removes an common annoyance for
users. This code will not work for all terminal emulators, but by adding
it in systemd we'll entice maintainers of those terminals to add support
for the sequences. For the terminals that don't support the sequence, we
get a bit of a slowdown of `< 1 ms`, which seems hardly noticeable. The
user can always set TERM explicitly to avoid this if upgrading to a
newer terminal emulator is not possible.
Closes https://github.com/systemd/systemd/issues/36994.
query_term_for_tty() is used in two places: in fixup_environment(),
which affects PID1 itself, and in build_environment(), which affects
spawned services. There is obviously some cost to the extra call,
but I think it's worthwhile to do it. When $TERM is set incorrectly,
basic output works OK, but then there are various annoying corner
cases. In particular, we get the support for color (or lack of it)
wrong, and when output is garbled, users are annoyed. Things like
text editors are almost certain to behave incorrectly. Testing in
test-terminal-util indicates that the time required to make a successful
query is on the order of a dozen microseconds, and an unsuccessful
query costs as much as our timeout, i.e. currently 1/3 ms. I think
this is an acceptable tradeoff.
No caching is used, because fixup_environment() is only called once,
and the other place in build_environment(), only affects services
which are connected to a tty, which is only a handful of services,
and often only started in special circumstances.
Fixes https://github.com/systemd/systemd/issues/36994.