In the majority of cases, this is caused by
sleep_supported() returning error. Hence it's
very likely that it would fail again, so
the fallback is not really useful. Instead,
honor the --force option for these verbs.
The systemd-confext use case description was mentioning an OSConfig
project which won't say much to users. Also, it's good to call out that
systemd-confext provides a reliable way to manage configuration because
in contrast to other tools it will remove all old configuration files.
According to the documentation in systemd.resource-control(5),
resource-control options may be used in mount, scope, service,
slice, socket and swap units.
While e.g. systemd.service(5) includes that information,
documentation for some other units does not.
The most problematic example is systemd.slice(5).
Its documentation states a slice unit may only contain [Install]
and [Unit] sections, while actually it may contain also a [Slice]
section with options from systemd.resource-control(5).
units/user/app.slice is an example of a slice unit having a [Slice]
section.
TEST-26-SYSTEMCTL is racy as we call systemctl is-active immediately
after systemctl kill. Let's implement --wait for systemctl kill and
use it in TEST-26-SYSTEMCTL to avoid the race.
In mkosi CI, we want persistent journals when running interactively
and runtime journals when running in CI, so let's add a credential
that allows us to configure which one to use.
Required for integration tests to power off on PID 1 crashes. We
deprecate systemd.crash_reboot and related options by removing them
from the documentation but still parsing them.
LinkLocalAddressing accepts a boolean. This can be seen by looking at
`link_local_address_family_from_strong(cont char *s)` in
`src/network/netword-util.c#L102-108` which falls back to
`address_family_from_string`, defined two lines above (L100)
using `DEFINE_STRING_TABLE_LOOKUP_WITH_BOOLEAN`.
Also: rename Handover → Handoff. I think it makes it clearer that this
is not really about handing over any resources, but that the executor is
out off the game from that point on.
With 1df4b21abd we started to default to
enrolling into the LUKS device backing the root fs if none was specified
(and no wipe operation is used). This changes to look for /var/ instead.
On most systems /var/ is going to be on the root fs, hence this change
is with little effect.
However, on systems where / and /var/ is separate it makes more sense to
default to /var/ because that's where the persistent and variable data
is placed (i.e. where LUKS should be used) while / doesn't really have
to be variable, could as well be immutable, or ephemeral. Hence /var/
should be a safer default.
Or to say this differently: I think it makes sense to support systems
with /var/ being on / well. I also think it makes sense to support
systems with them being separate, and /var/ being variable and
persistent. But any other kind of system I find much less interesting to
support, and in that case people should just specify the device name.
Also, while we are at it, tighten the checks a bit, insist on a dm-crypt
+ LUKS superblock before continuing.
And finally, let's print a short message indicating the device we
operate on.
The log files defined using file:, append: or truncate: inherit the owner and other privileges from the effective user running systemd.
The log files are NOT created using the "User", "Group" or "UMask" defined in the service.
When starting a container with --user, the new uid will be resolved and switched to
only in the inner child, at the end of the setup, by spawning getent. But the
credentials are set up in the outer child, long before the user is resolvable,
and the directories/files are made only readable by root and read-only, which
means they cannot be changed later and made visible to the user.
When this particular combination is specified, it is obvious the caller wants
the single-process container to be able to use credentials, so make them world
readable only in that specific case.
Fixes https://github.com/systemd/systemd/issues/31794
Enable the exec_fd logic for Type=notify* services too, and change it
to send a timestamp instead of a '1' byte. Record the timestamp in a
new ExecMainHandoverTimestamp property so that users can track accurately
when control is handed over from systemd to the service payload, so
that latency and startup performance can be trivially and accurately
tracked and attributed.
When an IO event source owns relevant fd, replacing with a new fd leaks
the previously assigned fd.
===
sd_event_add_io(event, &s, fd, ...);
sd_event_source_set_io_fd_own(s, true);
sd_event_source_set_io_fd(s, new_fd); <-- The previous fd is not closed.
sd_event_source_unref(s); <-- new_fd is closed as expected.
===
Without the change, valgrind reports the leak:
==998589==
==998589== FILE DESCRIPTORS: 4 open (3 std) at exit.
==998589== Open file descriptor 4:
==998589== at 0x4F119AB: pipe2 (in /usr/lib64/libc.so.6)
==998589== by 0x408830: test_sd_event_source_set_io_fd (test-event.c:862)
==998589== by 0x403302: run_test_table (tests.h:171)
==998589== by 0x408E31: main (test-event.c:935)
==998589==
==998589==
==998589== HEAP SUMMARY:
==998589== in use at exit: 0 bytes in 0 blocks
==998589== total heap usage: 33,305 allocs, 33,305 frees, 1,283,581 bytes allocated
==998589==
==998589== All heap blocks were freed -- no leaks are possible
==998589==
==998589== For lists of detected and suppressed errors, rerun with: -s
==998589== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
Follow-ups for 74c4231ce5.
Previously, the path is obtained from the fd, but it is closed in
sd_event_loop() to unpin the filesystem.
So, let's save the path when the event source is created, and make
sd_event_source_get_inotify_path() simply read it.
We look for the root fs on the device of the booted ESP, and for the
other partitions on the device of the root fs. On EFI systems this
generally boils down to the same, but there are cases where this doesn't
hold, hence document this properly.
Fixes: #31199
This commit adds support for loading, measuring and handling a ".ucode"
UKI section. This section is functionally an initrd, intended for
microcode updates. As such it will always be passed to the kernel first.
Resolve at attach/detach/inspect time, so that the image is pinned and requires
re-attaching on update, given files are extracted from it so just passing
img.v/ to RootImage= is not enough to get a portable image updated
This reworkds --recovery-pin= from a parameter that takes a boolean to
an enum supporting one of "hide", "show", "query".
If "hide" (default behaviour) we'll generate a recovery pin
automatically, but never show it, and thus just seal it and good.
If "show" we'll generate a recovery pin automatically, but display it in
the output, so the user can write it down.
If "query" we'll ask the user for a recovery pin, and not automatically
generate any.
For compatibility the old boolean behaviour is kept.
With this you can now do "systemd-pcrlock make-policy
--recovery-pin=show" to set up the first policy, write down the recovery
PIN. Later, if the PCR prediction didn't work out one day you can then
do "systemd-pcrlock make-policy --recovery-pin=query" and enter the
recovery key and write a new policy.
Running both sd-ndisc and sd-radv should be mostly a misconfiguration,
but may not. So, let's only disable sd-ndisc by default when sd-radv is
enabled, but allow when both are explicitly requested.
