Doc correction: UDEV and PRIVILEGED in single container app


I had been reviewing the docs and I found a couple errors in the sample files as they relate to my implementation of a single container using debian buster (possibly stretch and others).

Firstly, my single container should be privileged, but when evaluated by it does not correctly detect the PRIVILEGED status. I was able to hardcode this as a workaround.

Second, the docs often reflect UDEV=1 to enable UDEV which seems outdated as the correct variable setting is either “on/off” - search UDEV=1

This was fairly confusing but through trial and error unplugging my USB device I concluded that I needed to perform both of these steps (hardcode PRIVILEGED variable and set UDEV on) in order to get the container to see hotplug events (do the correct functions within

ENV container docker
#if hostname "$HOSTNAME" &> /dev/null; then
#       PRIVILEGED=false

Brief update here, I do set the hostname to an invalid one so that explains why the if statement fails, my $HOSTNAME variable contains underscores which explains why it doesn’t set PRIVILEGED to true, but this seems like a less than optimal way to determine the privileged state.

my implementation
hostname = examplehost
$HOSTNAME = example_host

Hi @kml001 thanks for the report. The detection of PRIVILEGED seems like a bug in the logic, perhaps @nghiant2710 can speak more about how or why that is not working. In the case of UDEV=1, both on and 1 should work, but I agree the documentation should be updated to be consistent

Maybe that was the intent, but if you examine here:

You will see that it evaluates against the “on” string, which won’t evaluate true if UDEV is set to 1.

if [ “$TESTVAR” == “on” ]; then
echo “1 and on are equivalent”

Thank you for this report. I think I’ve managed to get to the bottom here.

The example file you linked comes from base-images/examples/INITSYSTEM/systemd/systemd.v230/. The base-image for that image’s Dockerfile is balenalib/amd64-debian. That example however includes an file which replaces the from the balenalib/amd64-debian:buster base image (see build/). The base image’s handles parsing true/1 -> on here, but the replacement from the example directory does not perform this parsing step.

The link in the docs section you point out also has this parsing for the UDEV variable.

I’ll be checking with a colleague who works closer to these parts of the system to determine whether it’s simply a matter of ensuring that this UDEV parsing is present.

Hey @kml001, thank you so much for your findings. You’re right about the UDEV env var evaluation, it should be evaluated like this so 1, on or true will work. It’s my bad that this part was accidentally removed (since we no longer install systemd by default, I cleaned up the original script to create these examples and this check was removed at that point), I will fix the UDEV and privileged container check in the examples soon.