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.
Bug 1455134 - [NMCI] nmcli_general_profile_pickup_doesnt_break_network failed
Summary: [NMCI] nmcli_general_profile_pickup_doesnt_break_network failed
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: NetworkManager
Version: 7.4
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Francesco Giudici
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-24 10:25 UTC by Francesco Giudici
Modified: 2018-04-04 17:06 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-04-04 17:06:14 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Francesco Giudici 2017-05-24 10:25:52 UTC 
NetworkManager CI failure

Bringing up a dhcp connection, the connection gets stuck in acquiring the IP address.
Comment 3 Vladimir Benes 2017-06-18 16:42:13 UTC 
this failed again:
I think we need slightly different version for NM 1.8+. 

The original bug was talking about boot time failure. And this has to be simulated by deleting /var/run/NetworkManager while the service is down  


    Scenario: nmcli - general - profile pickup does not break network service
    * Add a new connection of type "ethernet" and options "ifname * con-name ethernet0"
    * Add a new connection of type "ethernet" and options "ifname * con-name ethernet1"
    * Bring "down" connection "ethernet0"
    * Bring "down" connection "ethernet1"
    * Execute "systemctl stop NetworkManager"
    * Execute "systemctl stop network"
    * Execute "rm -rf /var/run/NetworkManager"
    # Finish asserts the command exited with 0, thus the network service completed properly
    Then Finish "systemctl start NetworkManager.service && systemctl start network.service"

Nevertheless I am not sure what caused the issue in the version we have in place. I have linked a new test summary.
Comment 4 Francesco Giudici 2017-06-26 11:43:45 UTC 
(In reply to Vladimir Benes from comment #3)
> [...]
> 
> The original bug was talking about boot time failure. And this has to be
> simulated by deleting /var/run/NetworkManager while the service is down  
> 

Sure, the test fails for a different issue now, but it is the same test failing, so thanks for reopening the bug.

Thanks for debugging and exposing the reproducer: it was easy for me to reproduce. No useful logs to identify the issue were produced, so I will need to spend some more time on this.
Comment 5 Francesco Giudici 2017-08-04 16:05:17 UTC 
(In reply to Francesco Giudici from comment #4)
> (In reply to Vladimir Benes from comment #3)
> > [...]
> > 
> > The original bug was talking about boot time failure. And this has to be
> > simulated by deleting /var/run/NetworkManager while the service is down  
> > 
> 
> Sure, the test fails for a different issue now, but it is the same test
> failing, so thanks for reopening the bug.
> 
> Thanks for debugging and exposing the reproducer: it was easy for me to
> reproduce. No useful logs to identify the issue were produced, so I will
> need to spend some more time on this.

Well, I dug a bit on this.
I had the same behavior using the reproducer if one of the interface on which the connection was started had no dhcp server on the other side: the connection ended in a failure, and so the network.service.

Once all the available interfaces had a running dhcp on the other side, the network.service had no more failures.

The issue is related to network init scripts.
Looking at them, they would trigger the service to fail only if some required component is missing (e.g., ip-tools) or if one of the connections fails to activate. The latter is most probably what triggers the sporadic failure of this test.
Unfortunately, no network.service logs are collected. What can be done is to collect logs related to the network.service in the test in order to see what happens in future sporadic failures.
Comment 6 Francesco Giudici 2017-08-11 14:17:41 UTC 
Patch to collect logs from network.service:
https://github.com/NetworkManager/NetworkManager-ci/pull/12
Comment 8 Francesco Giudici 2018-04-04 17:06:14 UTC 
The issue looked like a race between network.service and NetworkManager.
The reported failure was from init scripts, but caused no issues.
No NetworkManager bugs here.
Moreover, race seems now fixed as it is not happening anymore on CI runs from a long time. I don't expect to see it again.
Closing.
Note You need to log in before you can comment on or make changes to this bug.