Doc correction: UDEV and PRIVILEGED in single container app

Hello,

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 entry.sh https://github.com/balena-io-library/base-images/blob/master/examples/INITSYSTEM/systemd/systemd.v230/entry.sh 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” https://www.balena.io/docs/reference/base-images/base-images/#major-change - 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 entry.sh).

Dockerfile.template:  
ENV container docker
ENV INITSYSTEM on
ENV UDEV on

entry.sh:
#if hostname "$HOSTNAME" &> /dev/null; then
        PRIVILEGED=true
#else
#       PRIVILEGED=false
#fi

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 entry.sh here: https://github.com/balena-io-library/base-images/blob/master/examples/INITSYSTEM/systemd/systemd.v230/entry.sh

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

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

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

The example entry.sh 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 entry.sh file which replaces the entry.sh from the balenalib/amd64-debian:buster base image (see build/). The base image’s entry.sh handles parsing true/1 -> on here, but the replacement entry.sh from the example directory does not perform this parsing step.

The entry.sh 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 https://github.com/balena-io-library/base-images/blob/master/examples/INITSYSTEM/systemd/systemd/entry.sh#L102-L106 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.