UDEV privileged detection appears to be unreliable when there are multiple privileged containers

I have an UP board which I am running multiple services on. Two services are privileged; one of the privileged services has UDEV=1.

However, when rebooting, or pushing changes, i get the error:
“Unable to start udev, container must be run in privileged mode to start udev!”

I have checked that the container is privileged.

The service is built using "balenalib/%%BALENA_MACHINE_NAME%%-ubuntu-openjdk:8-bionic-run
When I ssh to the host, i find that the dummy0 interface still exists. I am guessing its either a race condition between the two privileged containers or the ip link delete line is failing.

I’ve got a workaround, but I wanted to report the bug.

Could you grant us support access to this UP board, to let us investigate the problem?

Granted. The device is 29cf43b9d4b60aa11b99cdb1cd4a9c25.

I’ve also had the WiFi fail twice when left on overnight… An nmcli c down / up fixed it…

I forgot to note that I’ve been running the same containers on a Raspberry Pi and haven’t had these issues with it.

Hi @daniel.crowe, where do you see that error? (“Unable to start udev, container must be run in privileged mode to start udev!”)

I don’t see this error in the supervisor logs now. Perhaps they are gone due to a device reboot. If so, is it possible to enable persistent logging? So we can retrieve the logs across boots.

Next, is it fine to get the device out of the local mode?

Then, could you share your docker compose file with us?
(you could send it via private message if you prefer)

I’m asking these so we could reproduce the issue on our end.

Finally, if you would like, feel free to list the steps to reproduce the issue and your workaround in our relevant repo as an issue: https://github.com/balena-os/balena-up-board/issues