From 83d0edf5651b0e5861926363ce65f3e4a69fe08a Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Thu, 16 Nov 2023 11:12:00 +0100 Subject: [PATCH 1/2] man/sd_bus_process: fix confusion about "synchronous" An event loop is not "synchronous". So we shouldn't say that the client must "synchrounusly poll" if we recommend an event loop. Let's just say it should poll, and say that "sd_bus_wait()" is blocking, which is clearer and more correct than "synchronous". --- man/sd_bus_process.xml | 16 ++++++++-------- 1 file changed, 8 insertions(+), 8 deletions(-) diff --git a/man/sd_bus_process.xml b/man/sd_bus_process.xml index f16b30ec6c..8e142dd97a 100644 --- a/man/sd_bus_process.xml +++ b/man/sd_bus_process.xml @@ -41,14 +41,14 @@ Description - sd_bus_process() drives the connection between the client and the message bus. That is, - it handles connecting, authentication, and message processing. When invoked pending I/O work is executed, and - queued incoming messages are dispatched to registered callbacks. Each time it is invoked a single operation is - executed. It returns zero when no operations were pending and positive if a message was processed. When zero is - returned the caller should synchronously poll for I/O events before calling into - sd_bus_process() again. For that either use the simple, synchronous - sd_bus_wait3 call, or hook up - the bus connection object to an external or manual event loop using + sd_bus_process() drives the connection between the client and the message bus. + That is, it handles connecting, authentication, and processing of messages. When invoked, pending I/O + work is executed, and queued incoming messages are dispatched to registered callbacks. Each time it is + invoked a single operation is executed. It returns zero when no operations were pending and positive if a + message was processed. When zero is returned the caller should poll for I/O events before calling into + sd_bus_process() again. For that either use the simple, blocking + sd_bus_wait3 call, or + hook up the bus connection object to an external or manual event loop using sd_bus_get_fd3. From 99ad526f2ae579c412a1a756af684bbd445cc7ae Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Zbigniew=20J=C4=99drzejewski-Szmek?= Date: Thu, 23 Nov 2023 13:18:54 +0100 Subject: [PATCH 2/2] man: drop recommendation to use absolute paths in ExecStart*= The only reason to recommend this would be if people had multiple commands with the same name in the search path. This probably was never the best idea, and it happens rarely anyway. Since the patch that dropped requirement for full paths was introduced, we have dropped support for unmerged-usr and we're planning to drop support for split-bin at some point too. Many people effectively have just one directory in the search path, so there is even less reason to use an absolute path. So let's recommend just using the command name, which makes the unit file shorter and nicer to read. --- man/systemd.service.xml | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/man/systemd.service.xml b/man/systemd.service.xml index 123f1db30d..b43ec14c37 100644 --- a/man/systemd.service.xml +++ b/man/systemd.service.xml @@ -1421,9 +1421,9 @@ systems using split /usr/bin/ and /bin/ directories, and their sbin/ counterparts on systems using split bin/ and sbin/. It is thus safe to use just the executable name in case of executables - located in any of the "standard" directories, and an absolute path must be used in other cases. Using an - absolute path is recommended to avoid ambiguity. Hint: this search path may be queried using - systemd-path search-binaries-default. + located in any of the "standard" directories, and an absolute path must be used in other cases. + Hint: this search path may be queried using systemd-path search-binaries-default. + The command line accepts % specifiers as described in systemd.unit5.