Bug 1331172

Summary: pass pre-opened listener to libvirtd for session daemon startup
Product: Red Hat Enterprise Linux Advanced Virtualization Reporter: Cole Robinson <crobinso>
Component: libvirtAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED DEFERRED QA Contact: yafu <yafu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 8.0CC: dyuan, fjin, jsuchane, xuzhang, yafu
Target Milestone: pre-dev-freeze   
Target Release: 8.1   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-04-02 20:47:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1401400    

Description Cole Robinson 2016-04-27 20:51:58 UTC
From https://bugzilla.redhat.com/show_bug.cgi?id=1271183#c42

(In reply to Daniel Berrange from comment #42)
> This type of race condition will exist in libvirt for ever, as long as we
> have code which loops on connect, sleeping a finite amount of time. Before
> be78814ae was applied, we explicitly passed the pre-opened listener down to
> libvirtd, which would totally avoid any race between connect() and listen().
> The explanation in be78814ae as to why it was necessary to revert it doesn't
> really make sense, because it is talking about a race between daemon startup
> + listen() + connect() which would not even exist in the code it was
> removing.
> 
> I vote for reverting be78814ae and re-examining whatever problem led to that
> patch.


The commit in question is:

commit be78814ae07f092d9c4e71fd82dd1947aba2f029
Author: Michal Privoznik <mprivozn>
Date:   Thu Apr 2 14:41:17 2015 +0200

    virNetSocketNewConnectUNIX: Use flocks when spawning a daemon
    


We should investigate if there's a way to revive the original fd passing which allowed us to avoid the hardcoded timeout which is only bound to hit corner case issues.

Comment 6 Jaroslav Suchanek 2020-04-02 20:47:04 UTC
This bug was closed deferred as a result of bug triage.

Please reopen if you disagree and provide justification why this bug should
get enough priority. Most important would be information about impact on
customer or layered product. Please indicate requested target release.