Hello Toradex team,
I hope you are all doing great!
Hardware:
uname:
- Linux verdin-imx8mp-14777482 5.15.129-6.4.0+git.67c3153d20ff #1-TorizonCore SMP PREEMPT Wed Sep 27 12:30:36 UTC 2023 aarch64 aarch64 aarch64 GNU/Linux
Images tested:
- torizon-core-docker-verdin-imx8mp-Tezi_6.4.0+build.5.tar (STABLE Release)
Guest OS:
- macOS (M1 Pro ARM64)
- Linux ubuntu (VM x86_64)
Issue:
So my issue is the following, I want to run a docker container with a specific USB device but, I want the same container to run if the device is not plugged to notify the user that something is wrong rather than have nothing displayed on the screen.
So the device is the following:
crw-rw-r-- 1 root plugdev 237, 0 Nov 13 21:07 /dev/hidraw0
The command I run a the moment has the following flag: --device=/dev/hidraw0, but when the device is not pluged I have a docker error:
docker: Error response from daemon: error gathering device information while adding custom device "/dev/hidraw0": no such file or directory.
I tried to create a custom rules in udev to add a cgroup for the device link, without success… The rule is properly called but it doesn’t change the fact that I’m unable to use the device on the container with the flag: --device-cgroup-rule='c 237:* rmw'.
One solution is of course to add the --privileged flag to my command but I want to avoid that for obvious security reason.
I hope you will be able to help me on this regard.
Thanks in advance,
Best
M
Greetings @unablesalt,
Looking at the official Docker documentation: docker run | Docker Docs
As per the note it really seems the --device option is not to be used with ephemeral devices that may be plugged/unplugged at a moment’s notice. Now for USB devices that act as a drive device like a typical USB drive there’s a workaround described here: Automatic mounting of sdcard on boot
But your USB device seems like it’s not a drive type device, correct? So perhaps this other solution may not work for you.
That said, if your goal is just to notify that something is not plugged in and therefore something is wrong. Maybe if the device doesn’t exist you launch another container showing some kind of error/failure screen or something similar?
Best Regards,
Jeremias
Hello @jeremias.tx,
Thanks for reaching back so quickly !
This is unfortunately not a drive device, so the solution doesn’t work…
And since we are using the TorizonPlatform to update a docker-compose, I don’t think it’s possible to start the container conditionally (for what I read online).
So basically, there is no solution to my problem ?
Best,
M
So basically, there is no solution to my problem ?
Well not necessarily, we just have to get more creative about it. Docker compose let’s you start select services instead of the entire thing: docker compose up | Docker Docs
Now imagine you have a compose file that defines 2 services. One service adds your device and does the normal operation. The other does not add your device (cause it’s not attached), and throws up the error message.
This is the systemd service that starts the compose file on boot: https://github.com/toradex/meta-toradex-torizon/blob/kirkstone-6.x.y/recipes-containers/docker-compose-up/files/docker-compose.service
You could modify this to have a different ExecStart. Say you instead point this to a script you made instead. In this script you could check whether /dev/hidraw0 exists. If yes then you docker-compose up the normal service. If not then you instead bring up the error service.
That way via your script you can control which container (normal or error) gets brought up conditionally.
Best Regards,
Jeremias
Hello @jeremias.tx,
That’s a super smart way to do it! And it’s working!
I have one last question regarding this command:
docker run --rm -it -v /dev:/dev --device-cgroup-rule='c 254:* rmw' torizonextras/arm64v8-gpiod
Here we expose the complete /dev directory, is it a proper way to do it ? I believe we can have access to all the devices and directory that lies within /dev or is there some more security ? I read the documentation about --device and --volume and it’s a bit blurry in my mind. I just want to be sure I’m doing the right things for my docker.
Best regards,
M
That’s a super smart way to do it! And it’s working!
That’s great to hear I just made up that solution on the spot haha.
Here we expose the complete /dev directory, is it a proper way to do it ? I believe we can have access to all the devices and directory that lies within /dev or is there some more security ? I read the documentation about --device and --volume and it’s a bit blurry in my mind. I just want to be sure I’m doing the right things for my docker.
Well when considering permissions for in a container there’s 2 things you have to think of.
- First is giving the container file-access to that device.
- This means thinks like bind-mounts or volumes. In your example here you’re creating a volume for all of
/dev. This means in the container you can see all the files from the host. But this does not necessarily mean you can do anything with those files.
- This is where permission access comes in.
- Just cause a container can see a file from the host doesn’t mean it can do anything with it. You typically need to grant the container certain permissions depending on what the file is. This is usually via the
--device flag or some cgroup or maybe even running as a certain user in the container.
Now back to your question. If your goal is just to have your container “see” the files then yeah -v /dev:/dev would be okay. If you actually want to operate on these files well then you need something more like I said. I hope this helps clear things up.
Best Regards,
Jeremias
1 Like
Hello @jeremias.tx,
Thank you for your answer, it’s more clear now!
I set your previous answer as the solution.
Best regards,
M
