diff options
| author | beviu <contact@beviu.com> | 2025-09-30 16:00:34 +0200 |
|---|---|---|
| committer | beviu <contact@beviu.com> | 2025-09-30 16:27:54 +0200 |
| commit | 895946798f7471163dc6b7f23bb2e82df3be5212 (patch) | |
| tree | c0d80d2d378bb58d7cea1a6f63a88ab6d039c9e5 /pkgs/development/python-modules/robotframework-pythonlibcore/git@git.tavy.me:nixos | |
| parent | e9f00bd893984bc8ce46c895c3bf7cac95331127 (diff) | |
Revert "switch-to-configuration-ng: wait for NameOwnerChanged after systemd Reexecute"
This reverts commit 67b8817f26366b93f07be8841ae9001b5af4e246.
That commit introduces a new error when:
- switch-to-configuration-ng spawns the "per-user"
switch-to-configuration-ng (the one that does do_user_switch).
- That "per-user" switch-to-configuration-ng instance connects to the
D-Bus session bus, but the bus is not up yet.
- The D-Bus session bus is configured to use systemd socket activation
and is currently being started by the systemd user manager.
- The D-Bus session bus finishes starting. At this point, only
switch-to-configuration-ng is connected to it. Systemd is not
connected yet because it waits for a ready notification from the D-Bus
session bus.
- switch-to-configuration-ng starts listening for a NameOwnerChanged
signal with the org.freedesktop.systemd1 bus name.
- Systemd is notified that the D-Bus session bus is ready, so it
connects to it and acquires the name org.freedesktop.systemd1, which
triggers the NameOwnerChanged signal that we listen to.
- switch-to-configuration-ng marks systemd as reexecuted, but it's _not
started reexecuting yet_.
- Then switch-to-configuration-ng tells systemd to reexecute.
- The loop waiting for systemd to reexecute [1] is never entered.
- switch-to-configuration-ng asks systemd to restart a unit but that
fails because systemd is reexecuting and the method call is sent to
the old deamon.
The idea with #442756 was to:
1. Remove the timeout for the Reexecute method call because it would
fail in a non-obvious way when systemd took too much time to execute,
and that could happen when there are many .mount units.
2. While we're at it, use the NameOwnerChanged signal to determine when
systemd is done reexecuting before we proceed with the other systemd
calls, instead of waiting for the Reexecute method call to error.
But in fact, it seems like 2. is not a good idea. Waiting for the
NameOwnerChanged signal has the disadvantage of not letting us know if
it is due to our Reexecute method call or someone else's, or even just
systemd that's just connected to the D-Bus in between as is the case
here.
It might still be a good idea to increase the timeout for the Reexecute
method call to fix the original error, but at least let's revert the PR.
[1]: https://github.com/NixOS/nixpkgs/blob/ec481667d737b1b366ac55d72ec09d101d842533/pkgs/by-name/sw/switch-to-configuration-ng/src/src/main.rs#L989
Diffstat (limited to 'pkgs/development/python-modules/robotframework-pythonlibcore/git@git.tavy.me:nixos')
0 files changed, 0 insertions, 0 deletions
