Commit 32857f4
committed
worker: disconnect dbus from NameOwnerChanged signal (POO #183833)
This avoids us piling up signals we never handle and eventually
exceeding a dbus quota limit and causing all subsequent tap jobs
to fail.
New Net::DBus instances are automatically connected to this signal
on creation, you cannot change this. If the instance is kept
around but nothing iterates the dbus event loop once in a while,
that signal will just keep piling up messages indefinitely. We
encountered this once before in os-autoinst and "solved" it by not
persisting the dbus connection, but in this case it doesn't seem a
good idea to re-initialize that connection every time we want to
check on the status of a tap worker. So instead let's disconnect
it from the signal.
The 1 here is a bit magical. The Net::DBus connect_to_signal
method issues signal numbers on a first-come, first-served basis,
starting at 1 (0 is never used), and returns the number it
issued. When Net::DBus _new calls it, though, it doesn't record
the return value. So we have to know/guess that this will always
be the first signal connected.
Related ticket: https://progress.opensuse.org/issues/183833
Signed-off-by: Adam Williamson <[email protected]>1 parent 371ad64 commit 32857f4
2 files changed
+12
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
611 | 611 | | |
612 | 612 | | |
613 | 613 | | |
614 | | - | |
615 | | - | |
| 614 | + | |
| 615 | + | |
| 616 | + | |
| 617 | + | |
| 618 | + | |
| 619 | + | |
616 | 620 | | |
617 | 621 | | |
618 | 622 | | |
| |||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
80 | 80 | | |
81 | 81 | | |
82 | 82 | | |
| 83 | + | |
| 84 | + | |
| 85 | + | |
| 86 | + | |
| 87 | + | |
83 | 88 | | |
84 | 89 | | |
85 | 90 | | |
86 | 91 | | |
87 | 92 | | |
| 93 | + | |
88 | 94 | | |
89 | 95 | | |
90 | 96 | | |
| |||
0 commit comments