Frantisek Sumsal [Fri, 18 Feb 2022 22:09:18 +0000 (23:09 +0100)]
systemctl: make `--timestamp=` affect the `show` verb as well
Currently the `--timestamp=` option has no effect on timestamps shown by
`systemctl show`, let's fix that.
Spotted in #22567.
Before:
```
$ systemctl show --timestamp=us+utc systemd-journald | grep Timestamp=
ExecMainStartTimestamp=Sat 2021-12-11 15:25:57 CET
StateChangeTimestamp=Sat 2021-12-11 15:25:57 CET
InactiveExitTimestamp=Sat 2021-12-11 15:25:57 CET
ActiveEnterTimestamp=Sat 2021-12-11 15:25:57 CET
ActiveExitTimestamp=Sat 2021-12-11 15:25:57 CET
InactiveEnterTimestamp=Sat 2021-12-11 15:25:57 CET
ConditionTimestamp=Sat 2021-12-11 15:25:57 CET
AssertTimestamp=Sat 2021-12-11 15:25:57 CET
```
After:
```
$ systemctl show --timestamp=us+utc systemd-journald | grep Timestamp=
ExecMainStartTimestamp=Sat 2021-12-11 14:25:57.177848 UTC
StateChangeTimestamp=Sat 2021-12-11 14:25:57.196714 UTC
InactiveExitTimestamp=Sat 2021-12-11 14:25:57.177871 UTC
ActiveEnterTimestamp=Sat 2021-12-11 14:25:57.196714 UTC
ActiveExitTimestamp=Sat 2021-12-11 14:25:57.144677 UTC
InactiveEnterTimestamp=Sat 2021-12-11 14:25:57.176331 UTC
ConditionTimestamp=Sat 2021-12-11 14:25:57.176980 UTC
AssertTimestamp=Sat 2021-12-11 14:25:57.176980 UTC
resolved: rework how we reply to D-Bus messages for resolution requests
This reworks how we reply to D-Bus messages that come in for resolution
requests. Previously, we'd store them in the .bus_request field of
the main DnsQuery (but not any auxiliary one), and reply to it whenever
we had something to reply. In error paths this could mean we'd
accidentally reply twice.
This cleans this logic up: whenever we reply to a message we'll now go up
the tree of auxiliary queries, to find the primary query, i.e. the one
we actually want to reply to. Once we found it, we take out the bus
message object, resetting it to NULL. This way we can be sure we'll
reply at most once to each message.
pid1: set SYSTEMD_NSS_DYNAMIC_BYPASS=1 env var for dbus-daemon
There's currently a deadlock between PID 1 and dbus-daemon: in some
cases dbus-daemon will do NSS lookups (which are blocking) at the same
time PID 1 synchronously blocks on some call to dbus-daemon. Let's break
that by setting SYSTEMD_NSS_DYNAMIC_BYPASS=1 env var for dbus-daemon,
which will disable synchronously blocking varlink calls from nss-systemd
to PID 1.
In the long run we should fix this differently: remove all synchronous
calls to dbus-daemon from PID 1. This is not trivial however: so far we
had the rule that synchronous calls from PID 1 to the dbus broker are OK
as long as they only go to interfaces implemented by the broke itself
rather than services reachable through it. Given that the relationship
between PID 1 and dbus is kinda special anyway, this was considered
acceptable for the sake of simplicity, since we quite often need
metadata about bus peers from the broker, and the asynchronous logic
would substantially complicate even the simplest method handlers.
This mostly reworks the existing code that sets SYSTEMD_NSS_BYPASS_BUS=
(which is a similar hack to deal with deadlocks between nss-systemd and
dbus-daemon itself) to set SYSTEMD_NSS_DYNAMIC_BYPASS=1 instead. No code
was checking SYSTEMD_NSS_BYPASS_BUS= anymore anyway, and it used to
solve a similar problem, hence it's an obvious piece of code to rework
like this.
Issue originally tracked down by Lukas Märdian. This patch is inspired
and closely based on his patch:
pid1: lookup owning PID of BusName= name of services asynchronously
A first step of removing blocking calls to the D-Bus broker from PID 1.
There's a lot more to got (i.e. grep src/core/ for sd_bus_creds
basically), but it's a start.
Removing blocking calls to D-Bus broker deals systematicallly with
deadlocks caused by dbus-daemon blocking on synchronous IPC calls back
to PID1 (e.g. Varlink calls through nss-systemd). Bugs such as #15316.
Previously we'd only watch configured service bus names if Type=dbus was
set. Let's also watch it for other types. This is useful to pick up the
main PID of such a service. In fact the code to pick it up was already
in place, alas it didn't do anything given the signal was never received
for it. Fix that.
hwdb: 60-keyboard: Support the buttons on CZC P10T tablet
The machine has tree buttons connected to an EC that acts as a regular
AT-compatible keyboard controller. It can be either in "Windows 7" or
"Android" mode. It boots up with the earlier, but the Android build on
the tablet switches it on bootup (Windows presumably leaves it as-is).
The "Windows 7" mode, the behavior is very inconvenient: the Home button
emits multiple key presses that presumably do something in Windws 7 while
the second button toggles the RF Kill Switch in addition to producing a
scancode (it's labeled "Back" on Android version of the tablet).
The "Android" mode just sends the good ol' scan codes and this patch
handles them. On mainline Linux, the "x86-android-tablets" driver makes
sure we're in the correct mode.
Daan De Meyer [Thu, 17 Feb 2022 15:41:58 +0000 (15:41 +0000)]
mkosi: Add more packages required to run systemd-networkd-tests.py
Let's also add the required packages to run systemd-networkd-tests.py
for Ubuntu and Debian. The Fedora and Arch lists are also updated to
include python which is also required to run the tests.
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.
projects / thirdparty / systemd.git / log
