che-launcher self-destruct causes error

[creckord]

I've been trying out the new che-launcher based Che startup using Vagrant on my Windows 7 host. Although Che successfully starts, Vagrant exits with a provisioning error caused by the container_self_destruction implementation in che-launcher

Reproduction Steps:

1. Get Vagrantfile from https://raw.githubusercontent.com/eclipse/che/master/Vagrantfile
2. Run vagrant up

Expected behavior:

Provisioning completes without errors and Che starts.

Observed behavior:

Che starts, but the Vagrant up logs look a bit scary:

2016-08-08 13:08:16 ==> che: --------------------------------
2016-08-08 13:08:16 ==> che: ECLIPSE CHE: BOOTING ECLIPSE CHE
2016-08-08 13:08:16 ==> che: --------------------------------
2016-08-08 13:08:17 ==> che: INFO: ECLIPSE CHE: FOUND IMAGE codenvy/che-launcher:latest
2016-08-08 13:08:17 ==> che: INFO: ECLIPSE CHE: LAUNCHING LAUNCHER
2016-08-08 13:08:17 ==> che: Unable to find image 'alpine:latest' locally
2016-08-08 13:08:19 ==> che: latest: Pulling from library/alpine
2016-08-08 13:08:19 ==> che: e110a4a17941: Pulling fs layer
2016-08-08 13:08:21 ==> che: e110a4a17941: Verifying Checksum
2016-08-08 13:08:21 ==> che: e110a4a17941: Download complete
2016-08-08 13:08:21 ==> che: e110a4a17941: Pull complete
2016-08-08 13:08:21 ==> che: Digest: sha256:3dcdb92d7432d56604d4545cbd324b14e647b313626d99b889d0626de158f73a
2016-08-08 13:08:21 ==> che: Status: Downloaded newer image for alpine:latest
2016-08-08 13:08:22 ==> che: ip: can't find device 'eth0'
2016-08-08 13:08:22 ==> che: INFO: ECLIPSE CHE: ALREADY HAVE IMAGE codenvy/che-server:latest
2016-08-08 13:08:22 ==> che: INFO: ECLIPSE CHE: CONTAINER STARTING
2016-08-08 13:08:22 ==> che: INFO: ECLIPSE CHE: SERVER LOGS AT "docker logs -f che-server"
2016-08-08 13:08:22 ==> che: INFO: ECLIPSE CHE: SERVER BOOTING...
2016-08-08 13:08:37 ==> che: INFO: ECLIPSE CHE: BOOTED AND REACHABLE
2016-08-08 13:08:37 ==> che: INFO: ECLIPSE CHE: http://localhost:8080
2016-08-08 13:08:44 ==> che: Error: No such container: 4547d65d14058d49377a7cba84b30848a38f44ba16abbd03d65b2c35779abf2b
2016-08-08 13:08:44 The SSH command responded with a non-zero exit status. Vagrant
2016-08-08 13:08:44 assumes that this means the command failed. The output for this command
2016-08-08 13:08:44 should be in the log above. Please read the output to determine what
2016-08-08 13:08:44 went wrong.

This problem can be tracked down to the implementation of container_self_destruction() in dockerfiles/che-launcher/launcher_funcs.sh, which deletes the container it is running in. While the command seems to work (i.e. the container is removed afterwards), Docker doesn't seem to be very happy about it. The following happens when interactively doing the same as container_self_destruction() in a shell inside a docker container:

[vagrant@vagrant ~]$ docker run -it --name "che-launcher" -v /var/run/docker.sock:/var/run/docker.sock $(get_list_of_variables) --entrypoint=/bin/sh codenvy/che-launcher:latest -i
/ # docker ps -a
CONTAINER ID        IMAGE                         COMMAND                CREATED             STATUS              PORTS                              NAMES
12c31ab714d1        codenvy/che-launcher:latest   "/bin/sh -i"           6 seconds ago       Up 5 seconds                                           che-launcher
332610b65718        codenvy/che-server:latest     "/home/user/che/bin/   About an hour ago   Up About an hour    8000/tcp, 0.0.0.0:8080->8080/tcp   che-server
/ # hostname
12c31ab714d1
/ # docker rm -f $(hostname)
Error: No such container: 12c31ab714d13928d8c77931ac0e430c10d87959abdce61e5e88eee657833d23
[vagrant@vagrant ~]$ echo $?
1
[vagrant@snom15 ~]$ docker ps -a
CONTAINER ID        IMAGE                       COMMAND                  CREATED             STATUS              PORTS                              NAMES
332610b65718        codenvy/che-server:latest   "/home/user/che/bin/c"   About an hour ago   Up About an hour    8000/tcp, 0.0.0.0:8080->8080/tcp   che-server

As you can see, the container exits immediately with an exit code of 1 and it has been deleted.

I'm not sure what the intention is here for forcing the removal from inside the container this way. Wouldn't it be cleaner to do it "the docker way" and just run the container with --rm? Alternatively, I think the che.sh should expect this error and not propagate the error code to its caller.

Che version: see Additional Information
OS and version: Windows 7 SP1 (Host), CentOS Linux release 7.2.1511 (Core) (Vagrant Box)
Docker version:

[vagrant@snom15 ~]$ docker version
Client:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:
 OS/Arch:      linux/amd64

Server:
 Version:      1.12.0
 API version:  1.24
 Go version:   go1.6.3
 Git commit:   8eab29e
 Built:
 OS/Arch:      linux/amd64

Che install: Vagrant

Additional information:

[vagrant@snom15 ~]$ docker run -t --name "che-launcher" -v /var/run/docker.sock:/var/run/docker.sock $(get_list_of_variables) codenvy/che-launcher:latest info                                                                               ip: can't find device 'eth0'
DEBUG: ---------------------------------------
DEBUG: ---------  CHE DEBUG INFO  ------------
DEBUG: ---------------------------------------
DEBUG:
DEBUG: ---------  PLATFORM INFO  -------------
DEBUG: DOCKER_INSTALL_TYPE       = native
DEBUG: DOCKER_HOST_OS            = CentOS Linux 7 (Core)
ip: can't find device 'eth0'
DEBUG: DOCKER_HOST_IP            =
DEBUG: DOCKER_DAEMON_VERSION     = 1.12.0
DEBUG:
DEBUG:
DEBUG: --------- CHE INSTANCE INFO  ----------
DEBUG: CHE CONTAINER EXISTS      = YES
DEBUG: CHE CONTAINER STATUS      = running
DEBUG: CHE SERVER STATUS         = running
DEBUG: CHE IMAGE                 = codenvy/che-server:latest
DEBUG: CHE SERVER CONTAINER ID   = 332610b65718
DEBUG: CHE CONF FOLDER           = /home/user/che/conf
DEBUG: CHE DATA FOLDER           = /home/user/che/workspaces
DEBUG: CHE DASHBOARD URL         = http://localhost:8080
DEBUG: CHE API URL               = http://localhost:8080/api
DEBUG: CHE LOGS                  = run `docker logs -f che-server`
DEBUG:
DEBUG:
DEBUG: ----  CURRENT COMMAND LINE OPTIONS  ---
DEBUG: CHE_PORT                  = 8080
DEBUG: CHE_VERSION               = latest
DEBUG: CHE_RESTART_POLICY        = no
DEBUG: CHE_USER                  = root
DEBUG: CHE_HOST_IP               =
DEBUG: CHE_LOG_LEVEL             = info
DEBUG: CHE_HOSTNAME              = localhost
DEBUG: CHE_DATA_FOLDER           = /home/user/che
DEBUG: CHE_CONF_FOLDER           = not set
DEBUG: CHE_LOCAL_BINARY          = not set
DEBUG: CHE_SERVER_CONTAINER_NAME = che-server
DEBUG: CHE_SERVER_IMAGE_NAME     = codenvy/che-server
DEBUG:
DEBUG: ---------------------------------------
DEBUG: ---------------------------------------
DEBUG: ---------------------------------------
Error: No such container: f0c6a26187995745aae94841c8fb2a148803ee131bc5083ef66d586812173c4a

• Problem started happening recently, didn't happen in an older version of Che: Yes
• Problem can be reliably reproduced, doesn't happen randomly: Yes

[TylerJewell]

@creckord. This morning @l0rd and I reviewed this - and we have been witnessing similar issues. We have decided that we agree with you and the benefit of self-destruction is not worth the cost. We will remove this.

[TylerJewell]

Fix: #2057
You will have to rebuild codenvy/che-launcher:nightly to test this