Red Hat Bugzilla – Bug 1168657
nmcli hangs when deleting profile two times
Last modified: 2015-11-19 05:58:05 EST
Description of problem: deleting profile two times hangs nmcli. Version-Release number of selected component (if applicable): NetworkManager-0.9.11.0-6.git20141125.f32075d2.el7.x86_64 How reproducible: always Steps to Reproduce: [vbenes@trautenberg ~]$ nmcli connection add type ethernet con-name tralala ifname \* Connection 'tralala' (ee254b08-b73e-41b0-8c55-b8972e70e590) successfully added. [vbenes@trautenberg ~]$ nmcli connection delete id tralala tralala Actual results: Error: Connection deletion failed: Timeout was reached Expected results: no error Additional info:
The error seems to be in the daemon. nmcli sends too Delete() D-Bus calls, but it doesn't get any response/error for the second. Investigating...
I have fixed nmcli not to call delete (or down) for the same connection multiple times. The change is in upstream branch jk/nmcli-con-delete-rh1168657. That will fix the bug. Nevertheless, we still should look into NetworkManager itself to fix the D-Bus responses.
(In reply to Jirka Klimes from comment #3) > I have fixed nmcli not to call delete (or down) for the same connection > multiple times. The change is in upstream branch > jk/nmcli-con-delete-rh1168657. That will fix the bug. > > Nevertheless, we still should look into NetworkManager itself to fix the > D-Bus responses. could this hanging be caused libnm? ( https://bugzilla.redhat.com/show_bug.cgi?id=1079353#c41 )
I'd rather have the: g_signal_handlers_disconnect_by_func (G_OBJECT (connection), down_active_connection_state_cb, info); be done in down_active_connection_state_cb(), since connection_cb_info_finish() is called in two paths, and this disconnect is only relevant in one of them. The other caller of the connection_cb_info_finish() in that path (connection_op_timeout_cb()) passes a NULL connection so the code there wouldn't hit anyway. The rest looks good.
(In reply to Thomas Haller from comment #4) > (In reply to Jirka Klimes from comment #3) > > I have fixed nmcli not to call delete (or down) for the same connection > > multiple times. The change is in upstream branch > > jk/nmcli-con-delete-rh1168657. That will fix the bug. > > > > Nevertheless, we still should look into NetworkManager itself to fix the > > D-Bus responses. > > could this hanging be caused libnm? ( > https://bugzilla.redhat.com/show_bug.cgi?id=1079353#c41 ) I don't think so. I think it was caused by NM not sending any response to D-Bus call. (In reply to Dan Williams from comment #5) > I'd rather have the: > > g_signal_handlers_disconnect_by_func (G_OBJECT (connection), > down_active_connection_state_cb, > info); > > be done in down_active_connection_state_cb(), since > connection_cb_info_finish() is called in two paths, and this disconnect is > only relevant in one of them. The other caller of the > connection_cb_info_finish() in that path (connection_op_timeout_cb()) passes > a NULL connection so the code there wouldn't hit anyway. > Fixed. Pushed to upstream master as: f52e6bb cli: do not stall in 'nmcli connection delete/down' (rh #1168657)
Cherry-picked into nm-1-0: 1203f22 cli: do not stall in 'nmcli connection delete/down' (rh #1168657)
No hangs occur anymore. Verified on all supported architectures.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-2315.html