You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Per the commit message in runc, this should also fix these messages;
Apr 26 03:46:56 foo.bar systemd1: Couldn't stat device /dev/char/10:200: No such file or directory
coming from systemd on every container start, when the systemd cgroup driver
is used, and the system runs an old (< v240) version of systemd
(the message was presumably eliminated by 1).
A container should not have access to tun/tap device, unless it is explicitly
specified in configuration.
This device was already removed from docker's default, and runc's default;
- opencontainers/runc@2ce40b6
- https://github.com/moby/moby//commit/9c4570a958df42d1ad19364b1a8da55b891d850a
Per the commit message in runc, this should also fix these messages;
> Apr 26 03:46:56 foo.bar systemd[1]: Couldn't stat device /dev/char/10:200: No such file or directory
coming from systemd on every container start, when the systemd cgroup driver
is used, and the system runs an old (< v240) version of systemd
(the message was presumably eliminated by [1]).
[1]: systemd/systemd@d5aecba
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Was having a chat with @tianon, and he raised the question "how stable are these fixed numbers guaranteed to be"?
Curious; would it be an idea (and is there a good way?) to dynamically find the major/minor numbers (with a sync.Once) to propagate this list? Perhaps you have ideas on that @kolyshkin ?
"how stable are these fixed numbers guaranteed to be"?
Practically, they are set in stone. Not that there is any standard saying that /dev/net/tun is 10:200 or /dev/null is 1:3, but I bet these will never ever change.
"how stable are these fixed numbers guaranteed to be"?
Practically, they are set in stone. Not that there is any standard saying that /dev/net/tun is 10:200 or /dev/null is 1:3, but I bet these will never ever change.
Practically, they are set in stone. Not that there is any standard saying that /dev/net/tun is 10:200 or /dev/null is 1:3, but I bet these will never ever change.
Yes, that was roughly my expectation; "unlikely" to change (famous last words! 😂); was wondering if that's documented somewhere (and if there would be a place to document it, or to "formalise" it).
I guess if they ever decide to change that, we'll notice that pretty fast.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
thaJeztah
added
cherry-picked/1.5.x
A container should not have access to tun/tap device, unless it is explicitly
specified in configuration.
This device was already removed from docker's default, and runc's default;
Per the commit message in runc, this should also fix these messages;
coming from systemd on every container start, when the systemd cgroup driver
is used, and the system runs an old (< v240) version of systemd
(the message was presumably eliminated by 1).