Error response from daemon: Container XXX is not running [snap]

[marcosvrs]

Environment:
Intel NUC NUC7i5BNK - Ubuntu Server 18.04 - Xorg installed

Command:
sudo x11docker --xorg x11docker/xfce xfce4-terminal

Log:
https://pastebin.com/8nsJYGFf

Behavior:
During the command execution I can see a gray screen with an black X in the middle of the screen. After the command fail, the console login screen is shown.

[mviereck]

Thank you for the report!

Unfortunately, I have no idea yet what is going wrong. The same command works well here. I'll think about it.
The log only gives few informations at the failing point:

DEBUGNOTE[23:43:09,564]: storeinfo(): xinitrc=ready
DEBUGNOTE[23:43:09,577]: waitforlogentry(): dockerrc: Found log entry "xinitrc is ready" in xinit.log.
DEBUGNOTE[23:43:10,880]: storeinfo(): containerid=6e1aa186e9b237d732bb3d72e1990f258690c62a9ef67803953d4613ca658535
 
==> /home/marcosvrs/.cache/x11docker/x11docker-xfce-xfce4-terminal-38185725015/share/container.log <==
Error response from daemon: Container 6e1aa186e9b237d732bb3d72e1990f258690c62a9ef67803953d4613ca658535 is not running
 
==> /home/marcosvrs/.cache/x11docker/x11docker-xfce-xfce4-terminal-38185725015/message.log <==
DEBUGNOTE[23:43:11,334]: dockerrc: Container is up and running.
 
==> /home/marcosvrs/.cache/x11docker/x11docker-xfce-xfce4-terminal-38185725015/share/container.log <==
Error: No such object: x11docker_X121_x11docker-xfce-xfce4-terminal_38185725015

The container starts, x11docker gets a container id, but than it immediatly stops without further messages.

Do I see right that you access the server over ssh, but the server has its own monitor?

[mviereck]

Could you please run some tests for debugging?

• Please show me your docker version. Here it is:

$ docker --version
Docker version 19.03.3, build a872fc2f86

• x11docker checks and waits for PID 1 in container. Maybe that check somehow fails.
  Please try:

docker run --rm --detach --name mytest x11docker/xfce sleep 10
docker inspect --format '{{.State.Pid}}' mytest

This should show a valid PID. You might need to run the docker inspect command more than once, sometimes the PID is not available immediatly.

• Please run your example again:

 sudo x11docker --xorg x11docker/xfce xfce4-terminal

While the X server is visible, run docker ps and look if it shows a running container entry x11docker_X121_x11docker-xfce-xfce4-terminal_38185725015. (The numbers will be different).

[marcosvrs]

Thanks for the fast answer!

You're right. I have the Intel NUC connected to my TV and use SSH to control it. Actually, I want to run the Kodi docker image. But it throws the same error as the xfce4-terminal. I thought that the xfce4-terminal would reduce the complexity of finding the right spot.

Docker Version:
Docker version 18.06.1-ce, build e68fc7a

Checks for PID 1:

marcosvrs@ironman:~$ sudo docker run --rm --detach --name mytest x11docker/xfce sleep 10
[sudo] password for marcosvrs: 
Unable to find image 'x11docker/xfce:latest' locally
latest: Pulling from x11docker/xfce
5ae19949497e: Pull complete 
f84eb1d8d385: Pull complete 
Digest: sha256:9c55f8da4352af5a597ab5beb53826eb3d9529bb981dd6133e7ac77c84b90cdd
Status: Downloaded newer image for x11docker/xfce:latest
1c2457ee5e572e2a346935f4afe33ec8cb7c85ea4dd0a3a8def2f3cbcb6c67c6
marcosvrs@ironman:~$ sudo docker inspect --format '{{.State.Pid}}' mytest
8654

Check docker ps while running the x11docker container:
I ran watch -n 0.5 sudo docker ps and in another terminal I ran the xfce4-terminal x11docker image, but unfortunately I couldn't see any new docker container running. No info was shown.

[mviereck]

Checks for PID 1:
latest: Pulling from x11docker/xfce

It seems you did the check on another computer, probably your local client instead of the Intel NUC. Am I right? I just think so because you already had a test run with x11docker/xfce over ssh and the image would have been already available and would not need to be pulled again.
If so, please run your tests on the Intel NUC over ssh.

marcosvrs@ironman:~$ sudo docker inspect --format '{{.State.Pid}}' mytest
8654

That looks valid. So the container has another reason to stop immediately.

I ran watch -n 0.5 sudo docker ps and in another terminal I ran the xfce4-terminal x11docker image, but unfortunately I couldn't see any new docker container running. No info was shown.

Odd. Can you test the command on your local machine / without ssh?

 sudo x11docker --xorg x11docker/xfce xfce4-terminal

I am still a bit out of ideas, but I am sure we'll find something.

Blind guess: Try with --init=none. Maybe there is an issue with docker-init.

[marcosvrs]

Checks for PID 1:
latest: Pulling from x11docker/xfce

It seems you did the check on another computer, probably your local client instead of the Intel NUC. Am I right? I just think so because you already had a test run with x11docker/xfce over ssh and the image would have been already available and would not need to be pulled again.
If so, please run your tests on the Intel NUC over ssh.

No, actually I just wanted to run a clean test, so before I prune docker system to make sure everything is running like the first time. But I definitely ran on the right device (Intel NUC) via SSH

I ran watch -n 0.5 sudo docker ps and in another terminal I ran the xfce4-terminal x11docker image, but unfortunately I couldn't see any new docker container running. No info was shown.

Odd. Can you test the command on your local machine / without ssh?

 sudo x11docker --xorg x11docker/xfce xfce4-terminal

I will find a keyboard and try it directly on the device (without ssh)

I am still a bit out of ideas, but I am sure we'll find something.

Blind guess: Try with --init=none. Maybe there is an issue with docker-init.

I’ll try it later and send the results

[mviereck]

I will find a keyboard and try it directly on the device (without ssh)

That is nice! I somehow doubt that ssh causes the issue, but currently I cannot exclude it.

No, actually I just wanted to run a clean test, so before I prune docker system to make sure everything is running like the first time. But I definitely ran on the right device (Intel NUC) via SSH

Ok! Sorry for questioning this, I just needed to be sure.

Please run also a check running an executeable from host instead of a Docker container, e.g.:

sudo x11docker --xorg --exe xterm

Another check: Docker container without X:

x11docker --tty x11docker/xfce pstree

[marcosvrs]

Unfortunately, nothing worked :(
I'll list all commands executed and the pastbin link for the output. All commands were executed directly via the terminal (without SSH).

sudo x11docker --xorg x11docker/xfce xfce4-terminal

https://pastebin.com/FU2KwpZU

sudo x11docker --xorg --exe xterm

�[41mx11docker ERROR:�[0m Command 'xterm ' not found.

  Type 'x11docker --help' for usage information
  Debug options: '--verbose' (full log) or '--debug' (log excerpt).
  Logfile will be: 
  Please report issues at https://github.com/mviereck/x11docker

x11docker --tty x11docker/xfce pstree

https://pastebin.com/JBPC8QD0

The x11docker.log after all commands:
https://pastebin.com/fZGUcL9w

[mviereck]

Sorry for my delay in this. I'll set up a VM to check this out.

�[41mx11docker ERROR:�[0m Command 'xterm ' not found.

xterm is just an example for a possible host application. Please try with an arbitrary GUI application available on your host system.

You could also try the latest beta version (x11docker --update-master). It contains a few minor fixes. Though, I doubt that they affect your setup.

[marcosvrs]

Still didn't work. But I hope that the log now show something:
PS: Before and after updating to the latest beta version the output was the same.

sudo x11docker --xorg --exe bash

Output: https://pastebin.com/ameijuUe
x11docker.log: https://pastebin.com/f9Bz6f95
Xorg.log: https://pastebin.com/qRR0p2jz

[mviereck]

I've set up a VM with Ubuntu server 18.04 and installed packages xorg and docker.io.

I found and fixed one minor bug: There was a timeout error while pulling images in x11docker. x11docker terminated, but Docker continued to pull the image. It is fixed now, x11docker waits until the pull is ready.
Aside from that everything worked as expected. I cannot reproduce your issue.

There is one difference: package docker.io provides Docker version 18.09.7.
But you have Docker version 18.06.1-ce. Could you please update your Docker installation, and x11docker as well? How did you install Docker?

[marcosvrs]

Could you please update your Docker installation, and x11docker as well?

I tried to update docked, but it says that this is the latest version. x11docker updated correctly.

How did you install Docker?

It was installed during the installation of Ubuntu Server. Looks like docker was installed using Snappy. I might try to install Docker via apt, but I think it’s a workaround. We should try to make x11docker work also with the Snappy docker version...

[mviereck]

ok, the key is somewhere in snap / snappy.

I've removed package docker.io and installed snap in my VM and can reproduce the issue now.
In snap it shows docker version 18.09.9.

I did some first checks for possible failing commands, but with no success so far. I'll investigate further.

[marcosvrs]

Sorry to give this info just now... I didn't realize that Ubuntu didn't use apt to install docker during installation.

[mviereck]

Some partial success!

This one works:

sudo x11docker --newprivileges --xoverip --xorg x11docker/fvwm xterm

It seems to me that snap / snappy does some containerization that disturbs access to some host files.
--newprivileges allows to gain privileges a process did not have before. This is not needed for regular docker installations with e.g. apt. With this option the container user might be able to become root in container or to gain other privileges he should not have.
--xoverip is an inofficial/experimental x11docker option that connects the application over TCP network instead of sharing the X unix socket. (Note that this does not work with --hostdisplay).

Overall I'd say that this is just a bad integration done by snap / snappy.

If there is a way to detect that docker is installed with snap or snappy, x11docker could show a warning and give a hint to use --newprivileges --xoverip.
x11docker could also automatically set this along with a warning.
Can you show me which docker? With snap it is:

$ which docker
/snap/bin/docker

Sorry to give this info just now... I didn't realize that Ubuntu didn't use apt to install docker during installation.

No worries. Why should one think that the package manager is the reason for an issue?

[marcosvrs]

Worked! Amazing!!! I really appreciate your help and wish to solve this problem!

Can you show me which docker? With snap it is:

Yes, it's the same as yours: /snap/bin/docker.

I have just one problem left, but I think it's not related to x11docker, but to the image:
I tried to run kodi, but neither the CEC worked nor the audio. Do you agree that I create another issue here and close this one? Since this issue is solved.
Or should I directly open the issue on the docker image maintainer?
Log for more details:

• Output: https://pastebin.com/S63kH5kd
• x11docker.log: https://pastebin.com/CcwcRvbB

[mviereck]

Worked! Amazing!!!

Great! :-)

I tried to run kodi, but neither the CEC worked nor the audio.

What means CEC?

As for audio: Try --pulseaudio=tcp. Likely sharing a pulseaudio unix socket failed, as happened with the X unix socket before. Therefore this belongs to this ticket.

I am not sure if --gpu will work with snap.
Maybe sharing the GPU device files in /dev will fail due to snap restrictions.
Also --xoverip can be an issue for --gpu. You may need --hostnet, too.

In the log you are using --cap-default. I recommend to use --newprivileges instead.

[marcosvrs]

What means CEC?

HDMI-CEC. I can't control kodi with my TV remote.

As for audio: Try --pulseaudio=tcp
You may need --hostnet, too.
I recommend to use --newprivileges instead.

Thanks for the hints... I didn't try too much yet, but the image is working fine. I'll try the audio soon.

Edit:
Tried with --pulseaudio=tcp but it still didn't work.
The HDMI-CEC and the Audio problems might be related, since both are using the HDMI port.
Do I need to share the HDMI device or something like that?

[mviereck]

Tried with --pulseaudio=tcp but it still didn't work.

Pulseaudio over TCP should likely work. I doubt that it is related to the CEC issue.
Do you have pulseaudio running on the host? Check with pactl info.
Maybe the sound is just muted in pulseaudio.

You can check with:

x11docker --xoverip --newprivileges --xorg --gpu --pulseaudio=tcp x11docker/check

In tab "Hardware" there is a button "Sound check Pulseaudio".

There is also a "GPU" tab. It helps to check out GPU acceleration.

The HDMI-CEC and the Audio problems might be related, since both are using the HDMI port.
Do I need to share the HDMI device or something like that?

It may be a good idea to ask @ehough first, maybe he already has some experience in this. This may be worth a ticket in its docker-kodi repository.
You can try -- --privileged -- before the image name as a first check (but not as a solution).

[mviereck]

In latest commit x11docker detects Docker in /snap and configures itself accordingly.
You do not need --xoverip --newprivileges anymore.
Could you please try out?

[mviereck]

I've opened a new ticket #203 on how to share a CEC device. Could you please have a look?

[marcosvrs]

In latest commit x11docker detects Docker in /snap and configures itself accordingly.
You do not need --xoverip --newprivileges anymore.
Could you please try out?

Didn't work. I'm running the version 6.4.0.

[mviereck]

Didn't work. I'm running the version 6.4.0.

The latest commit is in the master branch. Please update with x11docker --update-master to get the latest version.

[mviereck]

Closing due to inactivity.
Probably fixed in master branch, would need a final check.
Especially --pulseaudio and --printer default to a TCP connection in snap and would need a check.