• David Johnson's avatar
    Fix a nasty docker/mkvnode.pl race inspired by bootvnodes/vnodesetup. · e468cc49
    David Johnson authored
    This is probably true for Xen too, but in some cases, the
    vnodesetup early-release hackwaitandexit timeout of 30 seconds
    causes a race condition.  Normally, the first node sets up
    significant network state, and sometimes flips MAC addresses
    around from interface to interface -- OR puts a physical interface
    into a bridge, then changes the bridge's MAC address.  There is a
    short window of time where both the bridge and the new member
    interface share a MAC address -- and if the tmcc ifconfig assembly
    process for vnodes following the first vnode resolves
    the wrong device's MAC address and uses that to flesh out the
    ifconfig info, the vnodesetup will be in a world of hurt (i.e., you
    might see an attempt to make a vlan device out of a vlan device).
    The chance of this happening is miniscule, but I've seen it.
    
    So, at least for docker for now, we protect the first vnode against
    the 30-second timeout in vnodesetup hackwaitandexit, and we wait for the
    actual running file to be written, or error.
    
    This is probably applicable to any linux mkvnode.pl path, but I suppose
    it would have been another hundred thousand vnode creates before I saw
    it again.
    e468cc49
bootvnodes 11.2 KB