cf063b8a1c
Instead of failing the event loop with a generic EXIT_FAILURE error code when exit-on-disconnect is used, let's propagate the error code instead of swallowing it. Whereas previously sd_event_loop() would always fail with exit code '1' when exit-on-disconnect is used with an sd-bus instance registered with the event loop that encounters a failure, now we'll correctly propagate the error to sd_event_loop() that caused sd-bus to fail and exit the event loop. Additionally, the error is now also properly propagated to outstanding reply callbacks for async dbus calls started with sd_bus_call_async() and friends, whereas before we always used ETIMEDOUT for these calls which is extremely confusing for users. Why is this confusing? We always start sd-bus instances asynchronously, in other words, sd_bus_start() will not actually wait until the bus instance is connected, but it'll happen in the background, either driven by the first sd_bus_call() when there is no event loop or by sd-event when there is an event loop attached to the sd-bus instance. Assuming an event loop is attached, when we fail to connect to the bus, the sd-bus instance will close down and the first async method call we queued will fail with ETIMEDOUT. Nowhere in this process do we inform the user that we failed to connect to the bus because of e.g. a permission error, except for a debug log message. By propagating the error to sd_event_exit() if exit-on-disconnect is enabled and always propagating it to outstanding reply callbacks, debugging failures becomes much easier as users will now get the actual error code causing the bus instance to close down instead of ETIMEDOUT and 1 respectively.
System and Service Manager
Details
Most documentation is available on systemd's web site.
Assorted, older, general information about systemd can be found in the systemd Wiki.
Information about build requirements is provided in the README file.
Consult our NEWS file for information about what's new in the most recent systemd versions.
Please see the Code Map for information about this repository's layout and content.
Please see the Hacking guide for information on how to hack on systemd and test your modifications.
Please see our Contribution Guidelines for more information about filing GitHub Issues and posting GitHub Pull Requests.
When preparing patches for systemd, please follow our Coding Style Guidelines.
If you are looking for support, please contact our mailing list, join our IRC channel #systemd on libera.chat or Matrix channel
Stable branches with backported patches are available in the stable repo.
We have a security bug bounty program sponsored by the Sovereign Tech Fund hosted on YesWeHack
Repositories with distribution packages built from git main are available on OBS