Jan Mueller
2018-10-22 13:40:48 UTC
Hello folks,
weâre facing the following issue:
An application does not receive DBUS signals via the DBUS file descriptor while waiting for a dbus-method response.
The basic setup: Two applications are communicating via DBUS, using a select() loop waiting for events on the dbus-fd.
The faulty procedure:
- Triggered by a timer event, Application A calls the dbus-method âtransmitâ of application B.
- During processing of the âtransmitâ-method, application B broadcasts a dbus-signal on which application A is matched on.
- Afterwards, application B sleeps for 5ms and then finishes its âtransmitâ-method by sending a response message towards application A.
- The dbus-fd of Application A does not trigger the select() afterwards (same for epoll() if implemented so).
Though âŠ
o ⊠when triggering sd_bus_process() manually, the signal is being receved in application A, meaning that the signal was in fact received and queued, but the event was not signalled.
o ⊠other processes, not being âblockedâ by waiting for a response-message, do also receive the signal.
We saw this behavior on multiple platforms, e.g. Linux kubuntu 4.4.0-137-generic with 229-4ubuntu21.1 and Debian Buster 4.18.0-2-am64 with systemd 239-10.
Attached you can find a simple example, including application A / B, a makefile and the correlating *.conf-files.
Thanks in advance and best regards,
Jan Mueller
weâre facing the following issue:
An application does not receive DBUS signals via the DBUS file descriptor while waiting for a dbus-method response.
The basic setup: Two applications are communicating via DBUS, using a select() loop waiting for events on the dbus-fd.
The faulty procedure:
- Triggered by a timer event, Application A calls the dbus-method âtransmitâ of application B.
- During processing of the âtransmitâ-method, application B broadcasts a dbus-signal on which application A is matched on.
- Afterwards, application B sleeps for 5ms and then finishes its âtransmitâ-method by sending a response message towards application A.
- The dbus-fd of Application A does not trigger the select() afterwards (same for epoll() if implemented so).
Though âŠ
o ⊠when triggering sd_bus_process() manually, the signal is being receved in application A, meaning that the signal was in fact received and queued, but the event was not signalled.
o ⊠other processes, not being âblockedâ by waiting for a response-message, do also receive the signal.
We saw this behavior on multiple platforms, e.g. Linux kubuntu 4.4.0-137-generic with 229-4ubuntu21.1 and Debian Buster 4.18.0-2-am64 with systemd 239-10.
Attached you can find a simple example, including application A / B, a makefile and the correlating *.conf-files.
Thanks in advance and best regards,
Jan Mueller