logind: fix bool/int confusion for KillUserProcesses bus property
sd-bus for compat with old C expects "int" for booleans. Internally we
prefer to use C99 "bool" however. When pointing a pointer to it, we need
to handle the fact that they are typically differently sized, hence use
te right accessors for it.
logind: fix internal types used for EnableWallMessages
The value is used as a boolean, but stored in an unsigned. It's exposed
with sd-bus default boolean handling which however expects a (signed)
int. Let's clear this up, and use "bool" for this everywhere in
non-local scope, and make sure that when we pass it to sd-bus we
properly pass an "int".
See
https://github.com/systemd/systemd/pull/20559#issuecomment-1028011030
for reasoning. Quoting:
> I think it should be OK to advertise extra stub listeners to local
> clients, but you prohibit this now. i.e. there are two different
> concepts here, and we shouldn't mix them up:
>
> 1. tracking configured dns servers and advertise them to local programs
> 2. actually using them ourselves
>
> I am pretty sure that our own stubs are OK for 1 but not OK for 2,
> hence we should filter at the time of use not at the time of parse.
Moving the Xen check before the CPUID check, in order to handle the case where
a Xen domain is nested within a hypervisor which can be detected by via the
CPUID check, had an unintended consequence of causing Dom0 to report as a Xen
VM when it is not nested.
This patch stops further checks once it has been determined that Dom0 is not
nested within another hypervisor, meaning that the non-nested case matches its
previous logic (where it does not report as a VM).
Also, tidy the conditionals for the Xen and UML checks by removing handling of
a VIRTUALIZATION_VM_OTHER result, which has no code path.
tests: allow running all the services with SYSTEMD_LOG_LEVEL
It should make it easier to figure out what exactly services do there.
For example, with SYSTEMD_LOG_LEVEL=debug userdbd (v249) prints
```
varlink-5: New incoming message: {"method":"io.systemd.UserDatabase.GetUserRecord","parameters":{}}
```
before it crashes and systemd-resolved prints
```
varlink-21: New incoming message: {"method":"io.systemd.Resolve.ResolveAddress","parameters":{"address":[127,0,0,1],"flags":0,"ifindex":1000000,"family":0}}
```
and those messages are helpful (especially when scripts causing them
aren't clever enough to keep track of random stuff they send to systemd
:-))
Daan De Meyer [Tue, 15 Feb 2022 11:50:31 +0000 (11:50 +0000)]
test: Stop using TextTestRunner in systemd-networkd-tests.py
If we assign our own test runner, passing arguments stops working
as unittest won't instantiate its own test runner after it parses
the arguments from sys.argv.
Consequence is that the tests will write to stderr now instead of
stdout since it doesn't seem possible to configure the stream that
unittest.main() will instantiate its test runner with so it'll
default to sys.stderr.
manager: if we are reexecuting, do not invoke any fallbacks
For https://bugzilla.redhat.com/show_bug.cgi?id=1986176:
if we are trying to reexecute, and this fails for any reason, we shouldn't
try to execute /sbin/init or /bin/sh. It is better to just freeze.
If we freeze it is easier to diagnose what happened, but if we execute
one of the fallbacks, we don't really know what will happen. In particular
the new init might just return, causing the machine to shut down. Or we
may successfully spawn /bin/sh, which could leave the machine open.
manager: do not ignore the return value from the main loop
If manager_loop() fails, we would print an error message, but then actually
ignore the error in main(), and potentially execute the shutdown binary.
I'm not sure how likely this is to happen in practice, but it seems sloppy.
So let's do the cleanup, but actually freeze() if manager_loop() returned
an error.
invoke_main_loop() is refactored to return the manager objective. This way
we don't need to pass a separate parameter to specify whether we are
reexecuting. Subsequent patch will make further use of the returned objective.
Frantisek Sumsal [Mon, 14 Feb 2022 19:19:51 +0000 (20:19 +0100)]
test: set `ReadWritePaths=$BUILD_DIR` when running w/ coverage
otherwise units using `DynamicUser=yes` won't be able to write the
coverage stats (currently affecting TEST-20-MAINPIDGAMES).
`DynamicUser=yes` implies `ProtectSystem=strict` and
`ProtectHome=read-only` and can't be overridden hence we need to
utilize `ReadWritePaths=` to work around that.
When checking if we look at the root directory we actually need to
compare both st_dev *and* st_ino. The existing check only checked the
latter. Fix that.
boot: suppress XBOOTLDR if same device as ESP when enumerating entries
On my local system I linked up the ESP and XBOOTLDR partitions, and
ended up with duplicate entries being listed. Try hard to detect that
and only enumerate entries in the ESP if it turns out that both dirs
have the same dev_t.
This should detect both bind mounted and symlinked cases and should make
our list output less confusing.
bootspec: make sure all return values are initialized on return of find_esp_and_warn()
THis makes sure that find_esp_and_warn() + find_xbootldr_and_warn()
follow our usual coding style that on success all return values are
initialized. We got that right in most successful codepaths out of these
functions, but missed the one where the paths are manually overwritten
via env vars.
bootctl: show more information about boot entry state in list
Let's improve display of boot entries and show what type they have (i.e.
boot loader spec type 1, or type 2, or auto-discovered or reported by
boot loader), and in particular mark entries the boot loader discovered
but we can't find (i.e. that likely vanished, or possibly couldn't be
found due to a misconfiguration) and that the boot loader didn't find
but we see (which are new, or possibly also the result of
misconfiguraiton).
This is supposed to be a replacement for #22161, but instead of hiding
vanished entries, highlights them, which I think is more appropriate for
a low-level tool such bootctl.
Quite often we compare uuids/id128 formatted as strings with specific
values. So far we usually used streq() for that. let's add a new
explicit helper for this in id128_equal_string() that compares a string
with an sd_id128_t and is more robust than a simple string comparison.
Moreover, we can mroe easily reuse the various defines we have for
specific UUIDs, for example those from gpt.h.
We expose various other forms of UUID helpers already, i.e.
SD_ID128_UUID_FORMAT_STR and SD_ID128_MAKE_UUID_STR(), and we parse
UUIDs, hence add a high-level helper for formatting UUIDs too.
This doesn't add any new code, it just moves some helpers
id128-util.[ch] → sd-id128.[ch], to make them public.
gpt-auto: properly handle case where we can't determine devno of /usr/ fs
get_block_device_harder() returns == 0 if the fs is valid, but it is not
backed by a single devno. (As opposed to returning > 0 if the devno is
valid). Let's catch this case and log a clear message, and don't bother
open the device in that case.
This is mostly cosmetical, as either way, systemd-gpt-auto-generator
doesn't work in scenarios like that.
sd-device: refuse opening device mit major/minor of zero early
device nodes with 0 dev_t are not real (and for that reason such inodes
are used as whiteouts in overlayfs, for example), hence refuse them
early. It seems wrong going to sysfs for something we know can't exist
anyway.
Frantisek Sumsal [Mon, 14 Feb 2022 11:20:02 +0000 (12:20 +0100)]
test: check for (possibly) missing test coverage
If the test logs contain lines like:
```
...systemd-resolved[735885]: profiling:/systemd-meson-build/src/shared/libsystemd-shared-250.a.p/base-filesystem.c.gcda:Cannot open
```
it means we're possibly missing some coverage since gcov can't write the stats,
usually due to the sandbox being too restrictive (e.g. ProtectSystem=yes,
ProtectHome=yes) or the $BUILD_DIR being inaccessible to non-root users.
Yu Watanabe [Thu, 10 Feb 2022 07:14:21 +0000 (16:14 +0900)]
test-dhcp6-client: cleanups
This does many cleanups. Most prominently,
- check the sents packet more strictly,
- make the packets used in the test more readable,
- unify callbacks.
Yu Watanabe [Mon, 7 Feb 2022 15:30:56 +0000 (00:30 +0900)]
fuzz-dhcp6-client: test multiple states
Then, now all three paths client_process_information(),
client_process_reply(), and client_process_advertise_or_rapid_commit_reply()
in client_receive_message() are fuzzed.
Yu Watanabe [Thu, 10 Feb 2022 12:44:28 +0000 (21:44 +0900)]
sd-dhcp6-client: append extra options before elapsed time option
The value of elapsed time option is determined in runtime and not
deterministic. It is hard to test the sent packets if it is located
in the intermidiate of the packet.