Bug 1378449 - systemd : Failed to execute operation: Connection timed out
Summary: systemd : Failed to execute operation: Connection timed out
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: systemd
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: systemd-maint
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-09-22 12:37 UTC by Petr Sklenar
Modified: 2021-03-11 14:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-02-13 21:08:21 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Petr Sklenar 2016-09-22 12:37:43 UTC
Description of problem:
this is issue related to Bug 1371205 

Version-Release number of selected component (if applicable):
systemd-219-30.el7.x86_64

How reproducible:
rarely, but its reproducible

Steps to Reproduce:
1. 
# modprobe dummy
# for i in $(seq 1 1 30000); do (ip li add dummy$i type dummy &); echo $i; done
2. right away with no delay try:
# systemctl daemon-reload
Failed to execute operation: Connection timed out
3. wait 1 minute
4. one single command `systemctl daemon-reload` works with no issue
5. for i in `seq 1 10`; do systemctl daemon-reload; done
# it shows error later or sooner

Actual results:
systemctl daemon-reload
Failed to execute operation: Connection timed out

Expected results:
Failed to execute operation: Connection timed out. Try again later :)
or some magic

Additional info:

Comment 4 Kyle Walker 2019-06-19 20:46:29 UTC
The systemctl command interacts with pid 1 via DBus. In the example given, it looks like the increase in devices is causing systemd some difficulty in enumerating and storing state for all of them as they are emitted from the kernel. On top of that, it also has to wake up and pass state information over to NetworkManager in the instance of dummy interfaces, and so that adds a bit more churn between systemd and DBus.

This is what I would assume is a fairly rare occurrence under normal operation.

Comment 7 Kyle Walker 2020-02-13 21:08:21 UTC
When Red Hat shipped 7.7 on Aug 6, 2019 Red Hat Enterprise Linux 7 entered Maintenance Support 1 Phase.

    https://access.redhat.com/support/policy/updates/errata#Maintenance_Support_1_Phase

That means only "Critical and Important Security errata advisories (RHSAs) and Urgent Priority Bug Fix errata advisories (RHBAs) may be released". This BZ does not appear to meet Maintenance Support 1 Phase criteria so is being closed WONTFIX. If this is critical for your environment please open a case in the Red Hat Customer Portal, https://access.redhat.com, provide a thorough business justification and ask that the BZ be re-opened for consideration in the next minor release.

Please see comment 4 for an explanation as to why this is likely occurring.


Note You need to log in before you can comment on or make changes to this bug.