set_xserver_args find inconsistent results with DOCKER_XSERVER_TYPE=auto

[pierrewillenbrockdfki]

Symptoms:

• exec.bash keeps asking for regenerating the container(note: this machine is accessed via ssh).
• xpra server is not started with correct parameter set (may not be related directly)

Investigation revealed that the configuration mismatches between the first exec.bash run and the automatic second run after the container has been regenerated. In the first run, DOCKER_XSERVER_TYPE=xpra was decided on, in the second run, it found DOCKER_XSERVER_TYPE=mount and the configuration for those.

I would guess that the SSH_* environment variables are not set the same in the second exec.bash run.

This has been worked around by setting DOCKER_XSERVER_TYPE=xpra in settings.sh.

[planthaber]

• exec.bash keeps asking for regenerating the container(note: this machine is accessed via ssh).

• Make sure you have an up to date fork: 32787f8
• Also renrew it once, the renewal is triggered when the run paramaters are changed, before 32787f8, the initial always needed renewal once after the inital ./exec.bash

• xpra server is not started with correct parameter set (may not be related directly)

The settings are only usable on container creation (docker run), which is done in the initial call of ./exec.bash, subsequent calls are using docker start / docker exec to run code. to update the parameters the container needs to be re-created. this is why the regeneration is requested.

It could be that the ssh detection is not functioning correctly for you, can you check if $SSH_CLIENT or "$SSH_TTY" is set on the pc you are accessing by ssh?

https://github.com/dfki-ric/docker_image_development/blob/master/.docker_scripts/docker_commands.bash#L138-L140

[pierrewillenbrockdfki]

That commit alone is not sufficient to resolve this issue. The SSH_CLIENT and SSH_TTY are both set. I cannot upgrade to an VERSION 4 image at the moment. (But i can just remove the VERSION file changes to test commits.)

Also maybe interesting, the second (automatic) invocation runs with elevated privileges compared to the first. It can modify .container_config.txt even if one has setup permissions so the normal user cannot.

[planthaber]

The .container_config.txt is only modified by the scripts outside of docker, so that has nothing to do with elevated docker privileges. If the scripts are raising them, because it is reqiured for features of the settings.bach (e.g. docker in docker) there is a clear warning (not if --privileged is already in the ADDITIONAL_RUN_ARGS).