RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
When this is set:
[root@dell-per720-03 ~]# ovs-vsctl show
ff69b73f-1ba4-466d-adb4-2c307125eab3
    Bridge "ovsbridge0"
        Port "port0"
            Interface "iface0"
                type: dpdk
                options: {dpdk-devargs="0000:42:00.1"}
    ovs_version: "2.11.0"
[root@dell-per720-03 ~]# nmcli  connection 
NAME         UUID                                  TYPE           DEVICE     
System em1   1ce245e5-a067-4a09-b51e-8cb698de6845  ethernet       em1        
ovs-bridge0  d3e3a6e9-4a1c-4877-b882-ad5cf41db0c9  ovs-bridge     ovsbridge0 
ovs-iface0   7715b60a-9e23-44c4-92cf-bc5a06ac2bc6  ovs-interface  iface0     
ovs-port0    8b884093-51c4-4a31-b07b-194259f6fcde  ovs-port       port0    


This takes ages:
[root@dell-per720-03 ~]# time systemctl restart NetworkManager

real	0m0.145s
user	0m0.013s
sys	0m0.013s

Version-Release number of selected component (if applicable):
openvswitch2.11-2.11.0-9.el8fdp.x86_64
dpdk-18.11-8.el8.x86_64
NetworkManager-1.19.5-23594.645bb49825.el8.x86_64

From the log attached I see that NM synchronously waits for the activation of NetworkManager-dispatcher service on service stop. The dbus-daemon requests systemd to activate the unit, but the request times out after 25 seconds.

I don't have any idea why this happens so I'm assigning the bug to systemd; perhaps someone more familiar with the unit activation mechanism can understand better what's going on.

This is systemd-239-15.el8.x86_64 on RHEL 8.1 Beta.

CI test added:
https://gitlab.freedesktop.org/NetworkManager/NetworkManager-ci/-/merge_requests/598

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 (NetworkManager bug fix and enhancement update), 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://access.redhat.com/errata/RHBA-2020:4499