Fix race condition causing containers to fail to start. Fixes #6. #7
Conversation
|
Thanks. This looks awesome. But why not mount whole |
| @@ -10,3 +10,6 @@ containers external IP, iptables will be configured to route container's traffic | |||
| A chain named `EXTERNAL_IP` is created in the `nat` table into which all the rules are added. | |||
| And one more empty chain is created after this one for any additional custom rules you might want | |||
| to add, named `AFTER_EXTERNAL_IP`. | |||
|
|
|||
| Please make sure `/run/xtables.lock` exists on the host before starting the container. | |||
There was a problem hiding this comment.
Can you explain why this mount is necessary?
There was a problem hiding this comment.
Added some extra explanation in the latest commit
|
Sorry for the delay, only just got back to this.
This would expose a lot more than necessary, potentially even sensitive data. I've updated and implemented the feedback in the latest commit in the PR, if there's anything else you'd like to see changed please let me know. |
I mean, with access to But having a file-only mount means that you have the whole issue with the file maybe not existing on the host. |
| preventing race conditions that can cause containers to fail to start. | ||
| If this file does not exist, Docker will incorrectly create it as a directory, which may cause issues both on the host and with the container. | ||
|
|
||
| ======= |
There was a problem hiding this comment.
This is leftover from some bad merge?
This change fixes host firewall race conditions causing containers to sometimes fail to start.
In order to avoid concurrent modification, iptables tracks locks in the file
/run/xtables.lock.In order for iptables inside a VM to respect the locking, it will need access to this file as well (moby/moby#12547 (comment)).
The downside of this implementation, as explained in above linked comment, is that, in some configurations, the lockfile may not exist when the container is started, and Docker will create it as a directory.
Sadly there's no reliable/non-hacky way to avoid this within the scope of this project that I know of, as any method to create this file would require root access, and the container user on the host is not likely to be root.