-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hotplugging devices in containers require a service restart #2240
Comments
@alexgg I don't think this applies, the supervisor never mounts |
@pipex maybe it's wrongly phrased - when the |
@alexgg I believe if the device doesn't exist the engine won't let you start the container. Removing the device won't remove the node in the container |
@pipex I see. what this is trying to capture is that hotplugging works when it's the container that remounts the Ideally what we would want would be for applications to be able to specify a non-existent I am guessing there is a mix of engine and supervisor changes to provide frictionless hotplugging support. |
I see, one way to do that would be for the supervisor to mount Is not truly hotplug, as the container would have to be restarted, and there is always the risk that the user may remove the device between the supervisor detecting the device and starting the new container |
When the supervisor bind mounts the
/dev
directory into the container is takes a snapshot of the device's/dev/
, and future hotplugged devices are not updated until the container is restarted.There is a workaround for container with at least
CAP_SYS_ADMIN
capabilities that is to remount the/dev/
directory:Relates-to: https://balena.zendesk.com/agent/tickets/2728
The text was updated successfully, but these errors were encountered: