Skip to content
This repository has been archived by the owner on Jun 20, 2024. It is now read-only.

Race between weavewait and proxy #1300

Closed
bboreham opened this issue Aug 14, 2015 · 0 comments
Closed

Race between weavewait and proxy #1300

bboreham opened this issue Aug 14, 2015 · 0 comments
Assignees
@bboreham
Labels
bug
Milestone
1.1.0

Comments

@bboreham
Copy link
Contributor

The proxy is coded to start client containers via weavewait, then send them a SIGUSR2 when everything is ready. However the container start is asynchronous, so it is possible that the proxy manages to send the signal before weavewait is listening for it, which will result in a hang.

Comments in #1258 suggest this has been seen in real life.
@rade rade added the bug label Aug 14, 2015
@rade rade added this to the current milestone Aug 14, 2015
@rade rade mentioned this issue Aug 14, 2015
Closed
This was referenced Aug 17, 2015
Merged
Merged
rade added a commit that referenced this issue Aug 28, 2015
@rade
Merge pull request #1314 from weaveworks/1209-wait-iface-netlink
6291a89 
Wait for ethwe via netlink, not via polling or signals

Fixes #1209. Fixes #1258. Fixes #1300.
@rade rade modified the milestones: current, 1.1.0 Aug 29, 2015
@rade rade mentioned this issue Jan 28, 2016
Closed
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees

@bboreham bboreham

Labels
bug
Projects
None yet
Milestone
1.1.0
Development

No branches or pull requests
2 participants
@rade @bboreham