refactor(discovery): use systemd D-Bus API#971
Conversation
|
Nice work, will review it later today 🙇 .
I think we still need it for the metadata providers, no? |
kakkoyun
left a comment
There was a problem hiding this comment.
It always awesome to have one less external dependency 👍
It was done to expose the kernel config, but after some testing, it has been proven unecessary: #892 (comment)
From what I have documented here, everything gathered in |
|
Let's merge and test it further. |
Co-authored-by: Kemal Akkoyun <kakkoyun@users.noreply.github.com>
|
FYI, this feature uses ~15% of the CPU cycles as of |
|
Shall we open an issue for this? |
|
Might be worth it, as I am not sure of the previous performance implications so this might be a win, perf-wise, but I am worried about the extra GC pressure this is adding |

This replaces the invocations of
systemdctlCLI by the systemd D-Bus API.This is still a polling approach, the module conveniently remembers the previous set of units and returns the changes only, allowing to trigger minimal discovery updates.
The D-Bus signals that would allow for this to be event-driven are unreliable, and although there is a workaround, I have observe many duplicated updates and easily fall into infinite loops of updates.
Using the D-Bus API permits to mount the D-Bus socket into the agent container to make it aware of the host systemd units. (note: I have also removed the
/procmount which is not needed,hostPID: trueis enough)Closes #760