[Cygwin] Interactive mode does neither gracefully fail nor work

[eine]

Coming form mviereck/runx#2

Executing /cygdrive/t/x11docker/x11docker x11docker/xfce xfce4-terminal works as expected. However, when option -i is used, x11docker errors while waiting for "xinitrc" to be ready.

$ /cygdrive/t/x11docker/x11docker -i x11docker/xfce bash
x11docker note: Using X server option --xwin

x11docker note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings. Compare issue #108 on github.

ls

x11docker ERROR: waitforlogentry(): dockerrc: Timeout waiting for entry "xinitrc is ready" in xinit.log
  Last lines of xinit.log:
winPointerWarpCursor - Discarding first warp: 1920 1080
(--) 5 mouse buttons found
(--) Setting autorepeat to delay=500, rate=31
(--) Windows keyboard layout: "0000040A" (0000040a) "Spanish", type 4
(--) Found matching XKB configuration "Spanish (Spain,Traditional Sort)"
(--) Model = "pc105" Layout = "es" Variant = "none" Options = "none"
Rules = "base" Model = "pc105" Layout = "es" Variant = "none" Options = "none"
winInitMultiWindowWM - DISPLAY=:2453.0
winMultiWindowXMsgProc - DISPLAY=:2453.0
winProcEstablishConnection - Clipboard is not enabled, returning.

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

x11docker.log

[mviereck]

The log file shows the successful start of /cygdrive/t/x11docker/x11docker x11docker/xfce xfce4-terminal.
Can you please provide one with option -i?

/cygdrive/t/x11docker/x11docker -i x11docker/xfce bash

[eine]

My bad. I run it twice now:

• x11docker.log
• x11docker2.log

[mviereck]

Thanks!
I found an issue I thought to be already fixed long ago. The function escapestring() returned "" instead of an empty string if its input was empty.
That caused variable Winpty to be not empty and mislead x11docker.
Now you should get a message and --interactive should be disabled automatically.

Another issue I see is that the log file shows many entries multiple times. This does not happen on Linux but on Windows only. I have no good idea why that happens.

[eine]

I see the message, but it stops there, instead of finishing.

$ /cygdrive/t/x11docker/x11docker -i x11docker/xfce bash
x11docker note: Using X server option --xwin

x11docker note: Windows firewall settings can forbid application access
  to the X server. If no application window appears, but no obvious error
  is shown, please check your firewall settings. Compare issue #108 on github.

x11docker note: Option -i, --interactive: On MS Windows you need 'winpty'
  to run x11docker in interactive mode. MSYS2 provides winpty as a package.
  On Cygwin it can be compiled from source. WSL isn't supported yet.
  Fallback: disabling option --interactive.


DEBUGNOTE[00:51:25,645]: Received SIGINT
DEBUGNOTE[00:51:26,495]: storeinfo(): error=130
DEBUGNOTE[00:51:28,276]: Terminating x11docker.
DEBUGNOTE[00:51:29,149]: time to say goodbye (finish)
DEBUGNOTE[00:51:32,780]: finish(): Checking pid 2679 (containershell): (already gone)
DEBUGNOTE[00:51:35,367]: finish(): Checking pid 1725 (watchmessagefifo):      1725    1183    1183     223208  pty0      197609 00:37:25 /usr/bin/bash
DEBUGNOTE[00:51:37,576]: finish(): Checking pid 1708 (watchpidlist): (already gone)
DEBUGNOTE[00:51:39,361]: finish(): Container still running. Executing 'docker stop'.
  Will wait up to 15 seconds for docker to finish.
DEBUGNOTE[00:51:43,055]: finish(): Container terminated successfully
DEBUGNOTE[00:51:46,278]: termpid(): Terminating 1725 (watchmessagefifo):      1725    1183    1183     223208  pty0      197609 00:37:25 /usr/bin/bash
DEBUGNOTE[00:51:48,649]: x11docker exit code: 130

[mviereck]

I see the message, but it stops there, instead of finishing.

This is expected behaviour: bash is running, so x11docker does not terminate. bash is not accessible because --interactive is disabled.

Alternatively, x11docker could exit with an error instead of giving a note only. What do you think?

[eine]

I believe it should exit. The user is requesting an unsupported configuration which the app (x11docker) cannot handle. It can exit with an error or just a warning, that's up to you. However, not existing is misleading because it might seem that something can be done, and it is not the case.

What's the behaviour with other similar contexts? For example, if I want to use --printer, but cups is not available, does it just show a warning? or does it fail?

[mviereck]

What's the behaviour with other similar contexts? For example, if I want to use --printer, but cups is not available, does it just show a warning? or does it fail?

In similar situations, x11docker gives a note that an option is not possible. It either enables a fallback, if possible (and tells about it), or it disables the option at all, like here with --interactive.
For example, if --pulseaudio is not possible, the fallback is --alsa along with a message. If --alsa is not possible, too, the option is disabled with a message.

--interactive is different because it can leave the user with an unusable session. So an error+exit might be approbate.

[eine]

I knew that it would try to fall back for most options, but I thought that it would always exit with error if no suitable solution is found. In this sense, having a different behaviour for -i would be inconsistent. However, as we both agree, that's probably the better fit for that case. Hence, I am ok with dealing with the inconsistency.

Alternatively, it would be possible to change the "last resort" exit code for all options. x11docker could have three valid exit codes: 0 (success), 1 (fail), -1 (warning). Anyway, I understand that this discussion goes beyond the issue.

[mviereck]

Now x11docker exits for -i without winpty in MSYS2/Cygwin/WSL1.
In WSL2 -i might work without winpty, that'll need a check.

Alternatively, it would be possible to change the "last resort" exit code for all options. x11docker could have three valid exit codes: 0 (success), 1 (fail), -1 (warning).

In general x11docker tries to return the exit code of the container application. From x11docker --help:

  0:     Success
  64:    x11docker error
  130:   Terminated by ctrl-c
  other: Exit code of command in container

Closing the ticket because all seems to be fixed. Thank you for testing and reporting!

[eine]

Now x11docker exits for -i without winpty in MSYS2/Cygwin/WSL1.
In WSL2 -i might work without winpty, that'll need a check.

Actually, I use VSCode on Windows, and I have configured the Terminal to use MSYS2. Interestingly, when I start docker from a terminal inside VSC I do NOT need to use winpty. However, if I execute the same command from a regular MSYS2 terminal (outside of VSC) I do need to use winpty. Honestly, I doubt that VSC is silently using MSYS2's winpty. Instead, I'd say that VSC has some built-in fake tty implemented in JavaScript/TypeScript.

In general x11docker tries to return the exit code of the container application. From x11docker --help:

  0:     Success
  64:    x11docker error
  130:   Terminated by ctrl-c
  other: Exit code of command in container

Yes. The numbers were made up. My proposal is to add another item to that list, which is x11docker caution. This is when x11docker is able to exit cleanly, but cannot fulfil the options requested by the user. Alternatively, the caution code might be +256, so that it is meaningful even if the container was executed but it exited with a non-zero code. I realised that codes must be 8bit. Never mind.

[mviereck]

Actually, I use VSCode on Windows, and I have configured the Terminal to use MSYS2. Interestingly, when I start docker from a terminal inside VSC I do NOT need to use winpty [...]. Instead, I'd say that VSC has some built-in fake tty implemented in JavaScript/TypeScript.

That's interesting. Maybe that VS terminal could run Cygwin and/or WSL1, too.
However, it might be too much effort for only few possible users to explore and document this. An xterm in container could be used similar to --interactive if one really needs it in Cygwin or WSL1.

[eine]

Agree. I know that VSCode can WSL through Remote - WSL. However, I am not sure about using either WSL or Cygwin as the terminal. Also, note that I mean VSCode, not VS.

Anyway, as you say, it is possible to use xterm, terminator or any other terminal as the first argument to the container. Alternatively, it is possible to start the container with command tail -f /dev/null and then docker exec -it or 'Attach' from VSC.

Actually, I've thought about writing a kind of "Docker command helper extension" for VSC, mostly meant to make using x11docker easier. It would allow to easily write/save/modify commands such as runx --no-auth -- x11docker --user=0 -- -v $(pwd):/src -- IMAGE tail -f /dev/null or runx --no-auth -- x11docker --user=0 -- -v /var/run/docker.sock:/var/run/docker.sock -v $(pwd):/src -- IMAGE tail -f /dev/null. Currently, it is possible to start/stop containers from VSC, but there is poor support for adding options apart from adding JSON files to the repos.

[mviereck]

Actually, I've thought about writing a kind of "Docker command helper extension" for VSC, mostly meant to make using x11docker easier. It would allow to easily write/save/modify commands

Maybe x11docker-gui could be extended a bit to store/load/change commands. However, it will be tricky to set the checkboxes right.

Are you aware that source runx --no-auth can be added to .bashrc so it runs in background all the time? This way you don't need to type it for each command.

[eine]

Maybe x11docker-gui could be extended a bit to store/load/change commands. However, it will be tricky to set the checkboxes right.

I guess the tricky part is how/where to save the list of preset commands so that it is easy to use and modify. Once that is available, I'm not specially concerned about using a GUI to do so. It would be handy, but not a requirement. My main issue now is that I don't want to maintain a separate and tiny script that would need to be installed explicitly. Ideally, I want to have the feature upstreamed to either x11docker or VSC's docker extension.

Unfortunately, there seems not to be enough demand for VSC developers to give it a try (microsoft/vscode-docker#1001). BTW, there is an interesting screencast in microsoft/vscode-docker#1496 (comment)

Actually, I think this would be a nice CLI feature for x11docker:

x11docker --preset interactive_as_root IMAGE

x11docker --preset as_root IMAGE xterm

x11docker --preset interactive_as_root_port5000 IMAGE

x11docker --preset interactive_as_root -p 5000 IMAGE

Unfortunately, because x11docker is written in Bash, I think it won't be easy to handle optional CLI arguments that override the defaults defined in each preset. I believe that either JS/TS or Python are better suited for this task.

Are you aware that source runx --no-auth can be added to .bashrc so it runs in background all the time? This way you don't need to type it for each command.

I know. But I do use MSYS2 terminal more than I do need docker with GUI features. Moreover, I normally use multiple terminals at the same time. Hence, on the one hand I don't want to have unauthenticated servers running when I don't need them. On the other hand, it is difficult to remember where did I start the X server or which port number I used.

[mviereck]

Actually, I think this would be a nice CLI feature for x11docker:

Let's discuss this in #218