"Must Be Connected to a Terminal Error" with Screen -X Command on a Linux Container

Docker: Could not connect to any X display

The solution is to run the following command in your terminal:

xhost +local:docker 

Then try again, it should work:

docker exec -it my_container

/# rqt
QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root'

The code command does not work when connecting to a Docker container remotely with VSCode

I'll answer myself as I was able to call VSCode using the code command in the remote's container.

When I look closely underneath home, I see that there was a code at the following directory.

$HOME/.vscode-server/bin/<directory with a hash-like name>/bin/

So I passed the PATH through it and it worked.

By the way, <directory with a hash-like name> is a directory with a hash-like name, which is randomly assigned when you connect to the container remotely. It's different every time, so please refer to it by yourself.

The way to register the path is as follows.

export PATH="$PATH:$HOME/.vscode-server/bin/<directory with a hash-like name>/bin/"

Thank you very much for your support.

X11 forwarding of a GUI app running in docker

Ok, here is the thing:

1) Log in to remote machine

2) Check which display was set with echo $DISPLAY

3) Run xauth list

4) Copy the line corresponding to your DISPLAY

5) Enter your docker container

6) xauth add <the line you copied>*

7) Set DISPLAY with export DISPLAY=<ip-to-host>:<no-of-display>

*so far so good right?

This was nothing new...however here is the twist:
The line printed by xauth list for the login user looks something like this (in my case):

<hostname-of-machine>/unix:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

Because i use the bridged docker setup, the X forwarding port is not listening locally, because the sshd is not running in the container. Change the line above to:

<ip-of-host>:<no-of-display> MIT-MAGIC-COOKIE-1 <some number here>

In essence: Remove the /unix part.

<ip-of-host> is the IP address where the sshd is running.

Set the DISPLAY variable as above.

So the error was that the DISPLAY name in the environment variable was not the "same" as the entry in the xauth list / .Xauthority file and the client could therefor not authenticate properly.

I switched back to an untrusted X11 forwarding setting.

The X11UseLocalhost no setting in the sshd_config file however is important, because the incomming connection will come from a "different" machine (the docker container).

screen Cannot open your terminal '/dev/pts/0' - please check

This happens because you may have done a sudo su user_name and then fired the screen command.

There are 2 ways to fix this.

  1. Login directly to "user_name" via ssh.
  2. Take ownership of the shell
    by typing script /dev/null as the user user_name and then type
    screen

How can I specify a display?

The way that X works is the same as the way any network program works. You have a server of some description (in this case, the X display server) which runs on a specific machine, and you have X clients (like firefox) that try to connect to that server to get their information displayed.

Often (on "home" machines), the client and server run on the same box and there's only one server, but X is powerful enough that this doesn't need to happen. It was built with the server/client separation built in from the start.

This allows you to do such wondrous things such as log on to your box (in text mode) halfway around the planet, tell it that the display server is the box you're currently on and, voila, the windows suddenly start appearing locally.

In order for a client to interact with a user, it needs to know how to find the server. There are a number of ways to do this. Many clients allow the -display or --displayoption to specify it:

xeyes -display paxbox1.paxco.com:0.0

Many will use the DISPLAY environment variable if a display isn't specifically given. You can set this variable like any other:

DISPLAY=paxbox1.paxco.com:0.0; export DISPLAY # in .profile
export DISPLAY=paxbox1.paxco.com:0.0 # in your shell
DISPLAY=paxbox1.paxco.com:0.0 firefox & # for that command (shell permitting)

The first part of the DISPLAY variable is just the address of the display server machine. It follows the same rule as any other IP address; it can be a resolvable DNS name (including localhost) or a specific IP address (such as 192.168.10.55).

The second part is X-specific. It gives the X "display" (X server) number and screen number to use. The first (display number) generally refers to a group of devices containing one or more screens but with a single keyboard and mouse (i.e., one input stream). The screen number generally gives the specific screen within that group.

An example would be:

+----------------------------------------+
|paxbox1.paxco.com| |
+-----------------+ |
| |
| +----------+----+ +----------+----+ |
| |Display :0| | |Display :1| | |
| +----------+ | +----------+ | |
| | | | | |
| | +-----------+ | | | |
| | |Screen :0.0| | | | |
| | +-----------+ | | | |
| | +-----------+ | | | |
| | |Screen :0.1| | | | |
| | +-----------+ | | | |
| | +-----------+ | | +-----------+ | |
| | |Screen :0.2| | | |Screen :1.0| | |
| | +-----------+ | | +-----------+ | |
| | +-----------+ | | +-----------+ | |
| | |Screen :0.3| | | |Screen :1.1| | |
| | +-----------+ | | +-----------+ | |
| | +-----------+ | | +-----------+ | |
| | | Keyboard | | | | Keyboard | | |
| | +-----------+ | | +-----------+ | |
| | +-----------+ | | +-----------+ | |
| | | Mouse | | | | Mouse | | |
| | +-----------+ | | +-----------+ | |
| +---------------+ +---------------+ |
| |
+----------------------------------------+

Here you have a single machine (paxbox1.paxco.com) with two display servers. The first has four screens and the second has two. The possibilities are then:

DISPLAY=paxbox1.paxco.com:0.0
DISPLAY=paxbox1.paxco.com:0.1
DISPLAY=paxbox1.paxco.com:0.2
DISPLAY=paxbox1.paxco.com:0.3
DISPLAY=paxbox1.paxco.com:1.0
DISPLAY=paxbox1.paxco.com:1.1

depending on where you want your actual windows to appear and which input devices you want to use.

OSX X11 Error cannot open display

So I finally got this to work. And it seems it was pretty simple. I am not certain how this actually fixes the issue, but now the containers work.

How I fixed it was opening up XQuartz and then opening up the "Terminal" app from the "Applications" menu. Then running the command export DISPLAY=192.168.1.X:0, then xhost +. It outputted something like this "access control disabled, clients can connect from any host". After that I was able to run my docker run commands to launch the desired GUI containers.

I am still uncertain how this works and not running them from my laptops Terminal app, but it worked. It must be something I have set in my local env. Hopefully this helps someone else out who may be running into the same issues.

Confused about Docker -t option to Allocate a pseudo-TTY

The -t option goes to how Unix/Linux handles terminal access. In the past, a terminal was a hardline connection, later a modem based connection. These had physical device drivers (they were real pieces of equipment). Once generalized networks came into use, a pseudo-terminal driver was developed. This is because it creates a separation between understanding what terminal capabilities can be used without the need to write it into your program directly (read man pages on stty, curses).

So, with that as background, run a container with no options and by default you have a stdout stream (so docker run | <cmd> works); run with -i, and you get stdin stream added (so <cmd> | docker run -i works); use -t, usually in the combination -it and you have a terminal driver added, which if you are interacting with the process is likely what you want. It basically makes the container start look like a terminal connection session.



Related Topics



Leave a reply



Submit