docker commit: recursion issue: [WARN tini (20)] Tini is not running as PID 1

[urbandroid]

Recreation steps:

$ x11docker --xpra -f --home -c --sudouser --user=RETAIN --pulseaudio --sharedir=$HOME/Downloads ucberkeley/firefox-browser-gui

then while that container running with new terminal connect with:

$ docker exec -it x11docker_X100_a622ed_ucberkeley-firefox-browser-gui bash

then in this terminal make some changes for example:

$ sudo apt update

$ sudo apt-get install software-properties-common

test installation with:

$ sudo add-apt-repository

installation successful.

then close that connected terminal or don't close it won't change the outcome, and with new terminal

$ docker commit "containerid" some/imagename

it should create the new image.

then close or don't close the container it won't change the outcome and try to start a new container from your newly created image:

with one of these:

$ x11docker --xpra -f --home -c --sudouser --user=RETAIN --pulseaudio --sharedir=$HOME/Downloads some/imagename
or
$ x11docker --xpra -f --home -c --user=RETAIN --pulseaudio --sharedir=$HOME/Downloads some/imagename
or
$ x11docker --xpra -f --home -c --pulseaudio --sharedir=$HOME/Downloads some/imagename
or
$ x11docker --xpra -f --home -c --pulseaudio --sharedir=$HOME/Downloads some/imagename

the output is like this:

[WARN tini (20)] Tini is not running as PID 1 and isn't registered as a child subreaper.
Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
[WARN tini (34)] Tini is not running as PID 1 and isn't registered as a child subreaper.
Zombie processes will not be re-parented to Tini, so zombie reaping won't work.
To fix the problem, use the -s option or set the environment variable TINI_SUBREAPER to register Tini as a child subreaper, or run Tini as PID 1.
[WARN tini (48)] Tini is not running as PID 1 and isn't registered as a child subreaper.
.
.
:

then terminate the process with frustration and ctrl + c then go to https://github.com/mviereck/x11docker/issues/new to create a new issue and win back your sanity.

Also this warning is not a just a warning and container does not function as it should be.

[mviereck]

Ok, I see ...
I'll check it out.
As a first shot, try to run the new image with --init=none.

[urbandroid]

Ok, I see ...
I'll check it out.
As a first shot, try to run the new image with --init=none.

Warning is gone but issue continues. This time there are no warnings but also there is no window even though xpra indicator indicates that there is a one. I don't know if 2 cases related to same cause or have different causes. also

x11docker note: Found 'USER 1000:1000' in image.
If you want to run with user 1000:1000 instead of host user me,
than run with --user=RETAIN.

this note on recently created image container can be a clue for you.

[mviereck]

I did some tests, it affects arbitrary images regardless of used options.
The issue seems to be a recursive call of /x11docker/x11docker.CMD.sh that is part of the CMD in the origin container and also gets created in the new container.

I have no idea yet how to allow docker commit and to avoid the recursion, I'll think over it.

Another approach:
Instead of docker commit build a new image with a Dockerfile, e.g.

FROM ucberkeley/firefox-browser-gui
RUN apt-get update
RUN apt-get install -y some-packages

A new image created this way will work without issues.

[mviereck]

I've had a closer look and don't see a good and clean way to resolve this.
I recommend to create new images with docker build instead as outlined above.

The latest commit to master branch detects this situation and exits with an error instead of running into the recursion loop.

Sorry that I cannot provide a better solution. Thank you for reporting this issue!

[mviereck]

To explain the issue:

The problem is that x11docker containers run with CMD command /x11docker/x11docker.CMD.sh. This is a dynamically generated script shared from host.

An image created with docker commit contains this command as CMD to execute, but does not contain the shared script. Running this new image with x11docker generates a file
/x11docker/x11docker.CMD.sh that recursively runs CMD /x11docker/x11docker.CMD.sh.

[mviereck]

I forgot this one:

docker commit stores command /x11docker/x11docker.CMD.sh although it does not exist in the created image.

You can use images created with docker commit from x11docker container, but must provide an image command to avoid the recursion.