mirror of
https://gitlab.freedesktop.org/NetworkManager/NetworkManager.git
synced 2025-12-29 08:00:18 +01:00
e678bd29a4
A D-Bus signal is asynchronous and it can happen that nm-dhcp-helper
emits the "Event" signal before the server is able to register a handler:
NM_DHCP_HELPER=/usr/libexec/nm-dhcp-helper
nmcli general logging level TRACE
for i in `seq 1 500`; do $NM_DHCP_HELPER & done
journalctl -u NetworkManager --since '1 min ago' | grep "didn't have associated interface" | wc -l
499
Avoid that, by calling the synchronous D-Bus method "Notify".
Interestingly, this race seem to exist since 2007.
Actually, we called g_dbus_connection_signal_subscribe() from inside
GDBusServer:new-connection signal. So it is not clear how such a race
could exist. I was not able to reproduce it by putting a sleep
before g_dbus_connection_signal_subscribe(). On the other hand, there
is bug rh#1372854 and above reproducer which strongly indicates that
events can be lost under certain circumstances.
Now we instead g_dbus_connection_register_object() from the
new-connection signal. According to my tests there was no more race
as also backed by glib's documentation. Still, keep a simple retry-loop
in nm-dhcp-helper just to be sure.
https://bugzilla.redhat.com/show_bug.cgi?id=1372854
https://bugzilla.redhat.com/show_bug.cgi?id=1373276
(cherry picked from commit
|
||
|---|---|---|
| .. | ||
| tests | ||
| Makefile.am | ||
| nm-dhcp-client-logging.h | ||
| nm-dhcp-client.c | ||
| nm-dhcp-client.h | ||
| nm-dhcp-dhclient-utils.c | ||
| nm-dhcp-dhclient-utils.h | ||
| nm-dhcp-dhclient.c | ||
| nm-dhcp-dhclient.h | ||
| nm-dhcp-dhcpcd.c | ||
| nm-dhcp-dhcpcd.h | ||
| nm-dhcp-helper-api.h | ||
| nm-dhcp-helper.c | ||
| nm-dhcp-listener.c | ||
| nm-dhcp-listener.h | ||
| nm-dhcp-manager.c | ||
| nm-dhcp-manager.h | ||
| nm-dhcp-systemd.c | ||
| nm-dhcp-systemd.h | ||
| nm-dhcp-utils.c | ||
| nm-dhcp-utils.h | ||