X11docker: Docker binary for init missing in openSUSE.

[Greenscreener]

x11docker ERROR: Docker startup seems to have failed! 

  Last lines of docker.log:
    27  export TERM=xterm
    28  export HOME=/home/jan
    29
    30  env > /x11docker/environment
    31  sed -i "/\(PWD=\|_=\)/d" /x11docker/environment
    32
    33  cd "$HOME"
    34
    35  exec $Dbus /usr/bin/kaptain /x11docker.kaptn >>/x11docker/stdout 2>>/x11docker/stderr
    36  # Ready for docker run

  Last lines of xterm.log:
Error: No such container: x11docker_X0_284fda_x11docker_kaptain
x11docker: container not ready on 8. attempt, trying again.
Error: No such container: x11docker_X0_284fda_x11docker_kaptain
x11docker: container not ready on 9. attempt, trying again.
Error: No such container: x11docker_X0_284fda_x11docker_kaptain
x11docker: container not ready on 10. attempt, trying again.
Error response from daemon: no such image: x11docker_X0_284fda_x11docker_kaptain: invalid reference format: repository name must be lowercase
x11docker: container IP:
x11docker: container PID:
Error: No such container: x11docker_X0_284fda_x11docker_kaptain

  Docker daemon messages:
Error response from daemon: Container 97c6d821f537ff2e6822c05444409cdbd4f6eae22495e439811b521575a80125 is not running
docker: Error response from daemon: exec: "docker-init": executable file not found in $PATH.
Error response from daemon: no such image: x11docker_X0_284fda_x11docker_kaptain: invalid reference format: repository name must be lowercase

[mviereck]

The core error message is exec: "docker-init": executable file not found in $PATH.. Maybe you have an outdated version of docker? Please show me the output of docker --version and of docker run --help | grep init.

It seems to me you have an old docker version without option --init. I have uploaded an update of x11docker-gui that does not use this and should work for you.

For your images you will probably have to set option --no-init to avoid this error. I recommend you to update docker.

[mviereck]

I've added a check in version 3.9.3 whether docker provides option --init and disables it otherwise. It will show a warning, but should work for you now without doing anything special. Thanks for reporting! Feel free to reopen if the issue persists.

[Greenscreener]

$ docker run --help | grep init
      --health-start-period duration   Start period for the container to initialize before starting health-retries countdown (ms|s|m|h) (default 0s)
      --init                           Run an init inside the container that forwards signals and reaps processes

$ docker --version
Docker version 17.09.1-ce, build f4ffd2511ce9

It doesn't appear older version of docker is the problem.

[mviereck]

Strange; your docker version supports option --init. From the error message above I thought you have a quite older version.

It doesn't appear older version of docker is the problem.

I don't think so now.
Can you please show me the full verbose output with option -v?

And can you try to run a docker image with option --no-init, for example

 x11docker -v --no-init x11docker/lxde pcmanfm

and show me the output if it fails?

[Greenscreener]

Output of x11docker lightworks --verbose: https://pastebin.com/PjkAu3QT

[Greenscreener]

I have the new version now btw.
If for instance, I run the x11docker-gui it just closes without no indication. In the cmd line it even returns just a 0 code.

[mviereck]

Can you please show me the output of

x11docker --verbose --no-init x11docker/lxde pcmanfm

?

The error message from your lightworks image could also mean that it has no CMD specified or the command is just not in PATH. Failing x11docker-gui could be a different issue. The command above should not fail in any case, I could analyze the output better.

[Greenscreener]

working on it, but it is downloading a lot of things (I don't have the lxde image)

[Greenscreener]

Output of x11docker --verbose --no-init x11docker/lxde pcmanfm: https://pastebin.com/et0xxqgE

[Greenscreener]

This is the Dockerfile of the lightworks image:

FROM ubuntu:latest
RUN apt-get update -y && apt-get upgrade -y
RUN apt-get install wget -y
RUN wget "https://www.lwks.com/index.php?option=com_docman&task=doc_download&gid=194" -O lightworks.deb
RUN dpkg -i lightworks.deb || true 
RUN apt-get install -f -y
RUN groupadd -r lightworks && useradd -r -g lightworks -G audio,video lightworks && mkdir -p /home/lightworks && chown -R lightworks:lightworks /home/lightworks
USER lightworks
ENTRYPOINT ["lightworks"]

[mviereck]

ok, I am building the lightworks image, will take a while, too. :-)

Did pcmanfm from lxde image run well? The logfile looks sane and successfull.

[Greenscreener]

What is pcmanfm?

[mviereck]

pcmanfm is the file manager of lxde that you have started with x11docker --verbose --no-init x11docker/lxde pcmanfm.

[Greenscreener]

oh yeah, I do not know how it is supposed to look normal, but it looked like a normal file manager to me.

[Greenscreener]

Some OS information:

$ cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20180227"
ID=opensuse
ID_LIKE="suse"
VERSION_ID="20180227"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20180227"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"

Linux OpenSUSE-WD-Elements-1042 4.15.5-1-default #1 SMP PREEMPT Thu Feb 22 21:48:29 UTC 2018 (52ce732) x86_64 x86_64 x86_64 GNU/Linux

[mviereck]

My image build is ready and lightworks runs fine :-).

Though, for option --hostdisplay (automatically chosen on your system) I need to add options --trusted and --ipc. It seems lightworks does not like untrusted cookies. (Options --gpu or --clipboard automatically switch to trusted cookies, than you would not need --trusted --ipc).

Give it a try with x11docker --verbose --clipboard lightworks

I am running debian 9. In a virtual machine I have openSUSE 42 LEAP, currently running an update over 500MB ... I will try there, too.

[Greenscreener]

Nope, still the same error.
Output of x11docker --verbose --clipboard lightworks: https://pastebin.com/EH1qEx8L

[mviereck]

Hm. Does it also fail with x11docker --verbose --clipboard --no-init lightworks ?

[Greenscreener]

It works, wait, I'll try to look around.

[Greenscreener]

So, I can't login. It says "Local MI read error."

[Greenscreener]

I'm going to have to leave my computer in a while, but I still have a few minutes. I'll be back at 13:00 GMT.

[mviereck]

You have this in your dockerfile:

RUN groupadd -r lightworks && useradd -r -g lightworks -G audio,video lightworks && mkdir -p /home/lightworks && chown -R lightworks:lightworks /home/lightworks
USER lightworks

This will not be regarded by x11docker as it runs the container as user jan. Maybe this has to be solved. You can try to run with option --user lightworks, but I'm not sure if that will work at first try.

We can have a look tomorrow again.

[Greenscreener]

Also, can I have like a mounted project folder or something?

[mviereck]

Yes, with option --sharedir /PATH/TO/FOLDER. A special shared folder is a virtual home folder on host with option --home.

[Greenscreener]

It gives x11docker ERROR: Unknown user or invalid user number 'lightworks' for option --user., but I really have to go now.

[mviereck]

Does the command more than creating a user with additional groups audio and video and create a home folder? If not, it should be ok to just run

x11docker --verbose --clipboard --no-init --home lightworks

Than you run the container as user jan with groups audio and video and a persistant home folder in /home/jan/x11docker/lightworks.

[mviereck]

ok, let's look again tomorrow. ;-)

[Greenscreener]

Thanks a lot for help so far, this is how opensource should work. And it does a lot of the time!

[mviereck]

It seems there is a bug in openSUSE's docker package. The binary for docker's builtin init system is missing. In openSUSE forum: https://forums.opensuse.org/showthread.php/529781-Docker-init-version-missing
As you already have an account there, would you please answer there and confirm the bug? Maybe it will get more attention than.

As a workaround for x11docker I have included a check that throws warning messages on openSUSE with the hint to use option --no-init, and additionally does a check at docker startup.

I can reproduce the "Local MI read error". I am not sure what lightworks is missing here as the docker container has a working internet connection. But I found that I can avoid the error if dropping the network namespacing of docker with x11docker option --net.

In summary, with options --ipc (in --clipboard) and --net you loose a lot of container isolation. But if your goal is rather to run an exotic package than to securely isolate it from your host system, that is ok.

This command should work fine so far. For hardware acceleration you can add option --gpu:

x11docker --verbose --clipboard --net --no-init --home lightworks

[Greenscreener]

Thank you very much, yes my only goal is to run lightworks under openSUSE, but it's not compatible (libraries and some other stuff are placed differently). The less the container is isolated, the better.

PS: wait, I mentioned that I have an account on openSUSE forums? No hard feelings, just wondering.
PPS: I am on my phone, so I can't test it, but I can answer questions I know.

[Greenscreener]

I answered the question on the forum, but I don't know where else to confirm the bug.

[mviereck]

PS: wait, I mentioned that I have an account on openSUSE forums? No hard feelings, just wondering.

No; big brother is watching you ;D. I get some statistics where the visitors of this github page come from, and there was a link to your "Lightworks docker image" thread with your user name. So I have an idea of what you've already tried and what you want to achieve.

I answered the question on the forum, but I don't know where else to confirm the bug.

Thanks! As I am not familar with openSUSE I would not know where to report, too. But at least it is documented and confirmed in the openSUSE forum.

[Greenscreener]

So, right now, I am on a different computer and I have my hard drive with me. It's probably an older hardware. So OS is the same. Runs normally without --gpu, but crashes with it:
Output of x11docker --verbose --clipboard --net --no-init --home --gpu lightworks: https://pastebin.com/fzuyY6JW

[Greenscreener]

Than you run the container as user jan with groups audio and video and a persistant home folder in /home/jan/x11docker/lightworks

I can't find /home/jan/x11docker/lightworks, in fact, the folder x11docker doesn't exist at all.

[mviereck]

oh, ok. x11docker automatically tries to run a secure X server setup and found kwin_wayland with Xwayland as a possible secure setup for --gpu. kwin starts quite slow and x11docker terminates with a timeout. It seems I need to set a longer timeout.

To avoid this mess use option --hostdisplay to explicitly use host X server.

I can't find /home/jan/x11docker/lightworks, in fact, the folder x11docker doesn't exist at all.

I'll check the --home option in my openSUSE VM.
Have a look at /home/jan/.local/share/x11docker/lightworks. x11docker should create a softlink to ~/x11docker, maybe that fails somehow.

[Greenscreener]

To avoid this mess use option --hostdisplay to explicitly use host X server.

Ok, works now.

Have a look at /home/jan/.local/share/x11docker/lightworks. x11docker should create a softlink to ~/x11docker, maybe that fails somehow.

Yep, found it. The symlink probably failed somehow, I'll make it manually. Thanks a lot.

[mviereck]

Ok, works now.

That is fine :-)
Have been some pitfalls on the way, now I have some things to think about how something can be easier.

Can you finally test x11docker-gui whether it runs now?

Yep, found it. The symlink probably failed somehow, I'll make it manually. Thanks a lot.

Did you find a possible reason why the symlink has failed the first time?

If you encounter issues with missing keys or strange characters, your image needs a locale to be installed. Change en_US to your preferred locale/language setting:

ENV LANG en_US.UTF-8
RUN echo $LANG UTF-8 > /etc/locale.gen
RUN apt-get install -y locales && update-locale --reset LANG=$LANG

The less the container is isolated, the better.

You can use option --homedir $HOME instead of --home to have your host home as container home. I do not recommend that in general, but may be fine for your use case.

Thanks for your detailed feedback, it helps me to improve x11docker. For myself everything works fine, and I am blind for the experience of one has who does not know x11docker already.

[Greenscreener]

I'm away for the whole weekend, maybe I'll be available each day around 18:00 GMT. Sorry.

[mviereck]

I will close this bug again as it is fixed so far; at least x11docker shows warnings on openSUSE and an error message on container startup.

Hopefully the bug will be fixed in openSUSE docker package some day as init in container is important for some things. For example, logout from desktops in container fail with --no-init.

I tried to make a bug report, but I got no user account at openSUSE. The confirmation email did not provide a confirmation code. Maybe the mail is only readable with html and javascript in the mail client, something I always disable in general.

[Greenscreener]

Can you finally test x11docker-gui whether it runs now?

Yes, tried the latest version, still acted the same. No output. Just exits after a few seconds with 0.

Did you find a possible reason why the symlink has failed the first time?

No idea. Created it manually, worked.

[mviereck]

Yes, tried the latest version, still acted the same. No output.

Odd. Runs well in my OpenSUSE VM. Could you please run with x11docker-gui --verbose and show me the output?

[Greenscreener]

Also, is there a way of making a (sym)link to a folder in my home to lightworks' home? Like for instance ~/Videos to ~/x11docker/lightworks/Videos? It doesn't work with a normal symlink, because the namespaced filesystem can't follow it. (At least I would think it works in this way?)

[mviereck]

Like for instance ~/Videos to ~/x11docker/lightworks/Videos?

Symlinks on host are difficult, docker does not handle that well.

The better way is to use --sharedir $HOME/Videos along with --home.

[Greenscreener]

Odd. Runs well in my OpenSUSE VM. Could you please run with x11docker-gui --verbose and show me the output?

Sorry didn't see your message.

Error: Parse error on line 59
Stuck __after__ the rule on line 58

[mviereck]

Odd again ...
That line is not very spectacular. It provides possible locale settings.
One way I can reproduce the error: If environment variable LANG contains quotation marks ". Can you please show me the output of:

echo "$LANG"

I have just uploaded a new version that deletes " in LANG, maybe that fixes it.

[Greenscreener]

$ echo "$LANG"
cs_CZ.UTF-8

[Greenscreener]

The same error appears even with LANG=C in place.

[mviereck]

cs_CZ.UTF-8 is a quite normal value for LANG, that is obviously not the cause. Thank you for testing this and also C.

I did some minor syntax changes, one of them may be the key.
Especially I changed

@combow('$Localescombo')="'"$LANG"'" "\" " | ! ""

to

@combow('$Localescombo')="'$LANG'" "\" " | ! ""

(There have been two unneccessary quotations).

Can you try again?
If it fails, please show me the output of x11docker-gui --verbose. Especially the first part showing the kaptain grammar is of interest, before the output of x11docker itself begins.

[Greenscreener]

x11docker-gui output of kaptain code: https://pastebin.com/y3Z90k2m

Error: Parse error on line 59
Stuck __after__ the rule on line 58

That was the only output of x11docker-gui when I ran it before.

[mviereck]

Thank you for the code!

Now I have installed openSUSE Tumbleweed in a VM, too.

I still cannot reproduce the error neither on openSUSE 42 LEAP nor on Tumbleweed, neither with image x11docker/kaptain nor with rpm package kaptain. Also tested with cs_CZ.UTF-8 locale. All tested with your kaptain code you provided above.

Only one possibility: Do you run x11docker-gui with the kaptain rpm package or with image x11docker/kaptain? Maybe you have an older image; I made some changes in it recently for better utf8 locale support. You can update the kaptain image with:

docker pull x11docker/kaptain

If you are using the kaptain rpm package, you can try to deinstall it and use the image instead.

[mviereck]

I've included a better check for docker-init. Now x11docker will set --no-init on itself, you don't need to make that yourself.

[Greenscreener]

I'm not sure if I have kaptain at all... Is that even possible? So best
version is from docker?

Dne so, 10. 3. 2018 15:00 uživatel mviereck [e-mail]
napsal:

Thank you for the code!

Now I have installed openSUSE Tumbleweed in a VM, too.

I still cannot reproduce the error neither on openSUSE 42 LEAP nor on
Tumbleweed, neither with image x11docker/kaptain nor with rpm package
kaptain. Also tested with cs_CZ.UTF-8 locale. All tested with your
kaptain code you provided above.

Only one possibility: Do you run x11docker-gui with the kaptain rpm
package or with image x11docker/kaptain? Maybe you have an older image; I
made some changes in it recently for better utf8 locale support. You can
update the kaptain image with:

docker pull x11docker/kaptain

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/mviereck/x11docker/issues/23#issuecomment-372032087,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AVXGW5cIe_7Fk16SE_3wl6gujXmeIsLMks5tc9xmgaJpZM4SXRr0
.

[mviereck]

I'm not sure if I have kaptain at all... Is that even possible?

:) If you are not sure, than you don't have it. It is not in openSUSE repository, but I provide it for manual installation: https://github.com/mviereck/kaptain

So best version is from docker?

The best one is one that works on your system - try to update the image, if that does not help, try out the rpm package.

[Greenscreener]

Dne so, 10. 3. 2018 15:00 uživatel mviereck [e-mail]
napsal:

Sorry, I used Gmail to reply and it automatically added this. It's the usual "sometime yesterday insert name wrote:", just in Czech as you probably have figured.

[Greenscreener]

What actually is kaptain anyway?

[mviereck]

What actually is kaptain anyway?

kaptain is a tool to create a GUI with a simple script. Usually, GUIs are using GTK or QT or something else to create a GUI, but need a language like C or Python.

For bash there is nothing to create a GUI; but kaptain allows me to write a kaptain script that creates a GUI with QT. So I don't need to learn C or Python.

The code you provided me is a kaptain script, created by x11docker-gui.

[Greenscreener]

Installed docker image, did nothing, tried to install rpm package, got this:

file /usr/share/man/man1/kaptain.1.gz from install of kaptain-0.73-2.x86_64 conflicts with file from package kde3-kaptain-0.72-1.40.x86_64

[mviereck]

Surprise ... it seems Tumbleweed reintroduced kaptain. It is not available on LEAP.

I am interpreting the message that you have package kde3-kaptain-0.72-1.40.x86_64 already installed. Can you check that?

[Greenscreener]

$ zypper se kaptain
Loading repository data...
Reading installed packages...

S  | Name         | Summary                                                 | Type   
---+--------------+---------------------------------------------------------+--------
i+ | kde3-kaptain | Universal Graphical Front-End for Command-Line Programs | package

yep (The “i” should mean it's installed)

More detailed output:

$ zypper if kde3-kaptain 
Loading repository data...
Reading installed packages...


Information for package kde3-kaptain:
-------------------------------------
Repository     : @System                                                
Name           : kde3-kaptain                                           
Version        : 0.72-1.40                                              
Arch           : x86_64                                                 
Vendor         : obs://build.opensuse.org/KDE:KDE3                      
Installed Size : 943,5 KiB                                              
Installed      : Yes                                                    
Status         : up-to-date                                             
Source package : kde3-kaptain-0.72-1.40.src                             
Summary        : Universal Graphical Front-End for Command-Line Programs
Description    :                                                        
    Kaptain is a universal graphical front-end for command line programs.

[mviereck]

!?!
Do you have KDE3 desktop on your system? That package is not part of the regular openSUSE repo. Maybe that version differs somehow from my kaptain version and causes the error.

How can I enable the KDE3 repo in Tumbleweed? I could check out that kaptain version and maybe reproduce the error.

Can you remove the package without loosing dependencies you would like to keep?

[Greenscreener]

Do you have KDE3 desktop on your system?

No. At least I haven't noticed yet. But really, no.

How can I enable the KDE3 repo in Tumbleweed?

I am not aware of it being enabled... I guess you could try this, but I have no actual idea how it originally got to my computer. I am kinda confused now. It isn't in the list of repos on my system either. Weird.

[mviereck]

Finally I can reproduce your error ...

The kaptain binary is in /opt/kde3/bin and I have to add that to PATH to execute kde3-kaptain. Maybe you should have a look at your /opt and your $PATH. :P

I may try to fix the issues with that kaptain version. Meanwhile, you could remove kde3-kaptain and try out kaptain image or my kaptain rpm.

[mviereck]

I've checked kde3-kaptain.
It shows version number 0.72, the actual version (since about 2006 ...) is 0.73.

I fixed the "Parse error after line xyz" bug (an array with more than 94 entries failed, now just reducing it to 1 default entry).

But the next error appears, some memory allocation error. It seems kaptain 0.72 is not able to handle my quite big x11docker-gui-script.

I won't try to fix that, too. Now x11docker-gui checks the version of kaptain and shows a warning for 0.72. Now it gives at least a message instead of failing silently.

[mviereck]

Ok, now a passable workaround: x11docker-gui checks version of kaptain. For version 0.72 from KDE:KDE3 repo it shows a warning and uses image x11docker/kaptain instead.

[Greenscreener]

Good, removed kde3-kaptain and it used the docker image and everything is working. At least I hope so.

[mviereck]

A summarization about missing init in docker:

For unknown reasons, some docker packages are missing the init binary /usr/bin/docker-init. This is at least true for openSUSE, fedora, CentOS and deepin.
This is a bug in docker package and should be reported to the distribution package maintainers. docker run --help shows option --init, but it fails.

My installation from docker repository shows:

$ docker --version
Docker version 18.03.1-ce, build 9ee9f40
$ docker-init --version
tini version 0.13.0 - git.949e6fa
$ docker run --help | grep " --init"
    --init        Run an init inside the container that forwards signals and reaps processes

tini is available on github: https://github.com/krallin/tini
docker uses the statically linked https://github.com/krallin/tini/releases/download/v0.13.0/tini-static

Current solutions to get tini in container if docker run option --init fails:

• Installing tini in image and using it as ENTRYPOINT: tini installation instructions for Docker images
• With x11docker: Downloading a tini-static version and storing it at one of
  
  
  
  • ~/.local/bin/x11docker (current user only)
  
  
  • /usr/local/x11docker (system wide)
  
  
• Latest tini-static is version 0.18.0: https://github.com/krallin/tini/releases/download/v0.18.0/tini-static
• Maybe it is possible to manually install tini-static as /usr/bin/docker-init. Maybe docker will recognize and use it. But even better the distribution packages should be fixed.