/dev symlinks created by udev not appearing in containers

Product support balenaOS
1

Hi All,

I have some udev rules setup in my config.json to create some consistent symlinks to various devices regardless of order theyare plugged etc. I’m running a multi container app with two containers that require access to two different USB devices.

The udev rules are working and I can see the symlinks in /dev on the host OS however they are not appearing in /dev within the containers consistently. Sometime the symlinks appear in one container and not the other. Restarting the host, the application or the containers does not appear to make the symlinks appear in /dev on the containers consistently either.

Configuration details:
balenaOS 2.47.0+rev1 (dev)
Supervisor: 10.6.27

udev rules in config.json:

{
  "os" : {
    "udevRules": {
       "100" : "ATTRS{serial}==\"4a389b1f7644e811ae655e9b885bad01\", SYMLINK+=\"ttySensor1\"",
       "101" : "ATTRS{serial}==\"f441106bb144e811a1925f9b885bad01\", SYMLINK+=\"ttySensor2\""
    }
}

In hosts /dev:
ttyUSB0 -> ttySensor1
ttyUSB1 -> ttySensor2

Container config in docker compose:

  ...

  sensor1:
    build: ./sensor1
    environment:
      - UDEV=1
    privileged: true
    devices:
      - '/dev:/dev'
    restart: always

  sensor2:
    build: ./sensor2
    environment:
      - UDEV=1
    privileged: true
    devices:
      - '/dev:/dev'
    restart: always

    ...

Both containers use image:
FROM resin/%%RESIN_MACHINE_NAME%%-ubuntu:bionic AS build

Hoping I have screwed up/missed something basic.

Thanks in advance.

Cheers
Chris

2

Hi Chris. Thanks for the report. That is very strange indeed. I noticed two things that might be causing this inconsistency. The first is that you are using the older resin/ base image. These are now deprecated and a lot of the reasoning around that was due to the init systems in those images causing issue with udev and plugged devices. So my first suggestion would be to switch to the balenalib/ equivalent base image.

The second this is that if you are using privileged on your services, then you don’t need the devices directive in your docker-compose.yml and I think that can also cause issues to use both, so I would remove those as well. Please let us know if you get to try both of these and if it makes any difference to the inconsistencies

4

Hi @shaunmulligan,

Thank you for fast response. All good suggestions regardless of issue. That’ll teach me to copy an old test project as the basis of this new image.

Images are now built from balenalib base images and I have removed duplication or privileged/dev mount.

Unfortunately still no result.

I have also since tried rolling back a few version of balenaOS and supervisor, nothing appears to have made a difference. I’ll continue to investigate and report back if I find anything.

Cheers
Chris

5

I actually think after reviewing everything what I am trying to do isn’t possible. When I take a step back what - I’m trying to achieve is reliable access with the containers to attached devices by assigning them a static name with symlink functionality of udev.

This is possible in the host context but upon further reading docker does not appear to support symlinks when you pass through all attached devices with:

devices:
    - '/dev:/dev'

So what I really have to do is pass through each individual device with:

devices:
    - '/dev/sensor1:/dev/sensor1'
    - '/dev/sensor2:/dev/sensor2'

The reason I was trying to avoid this approach is that if the device is not attached to the host OS the container won’t start until it is attached. I can’t think of anyway to avoid that.

Thanks for you help anyway.

Cheers
Chris

7

I am facing a similar issue and the solution seems to be to use a balenalib image and include this line in the Dockerfile.template:

ENV UDEV=1

This seems to pass through the udev-created symlinks to the container.

1 Like
8

@semireg I tried this with balenalib/raspberrypi3-python:3.9 and it didnt work. Were you successful in getting symlinked devices to appear by this method? Which balenalib image were you using?

9

My problem was solved by this post:

I was overriding the ENTRYPOINT. By switching mine to CMD and letting the provided ENTRYPOINT do what it needed to setup udev I can now access the symlinked dev points setup by udev.

1 Like