Commands sent to docker daemon hang when starting a Libre Office server inside the MFR container

[rija]

I'm running MFR in a Docker container using the supplied Dockerfile, When I starts Libre Office Server in the container using unoconv --listener to allow preview of Office documents, the docker container becomes irresponsive to control (cannot exit the shell, docker stop, restart or exec hang ).

I have to shutdown the docker-machine and restart in order to gain access of the container again.

I run docker on Mac OS X, using docker-machine with Docker v1.12.0

below is how I start my container

$ git clone http://github.com/centerforopenscience/modular-file-renderer/
$ cd modular-file-renderer

$ docker build -t="mfr" .

$ docker run -d -p 7778:7778 \
   -e SERVER_CONFIG_ADDRESS=0.0.0.0 \
   -e SERVER_CONFIG_PROVIDER_NAME=http \
   -e SERVER_CONFIG_ALLOWED_PROVIDER_DOMAINS=http://www.example.com/  \
   --name mfr_server \
   mfr

and how I run the Libre Office server:

 $ docker exec -it mfr bash
 $ unoconv --listener &

which will launch soffice.bin process

If I kill the unoconv process, the soffice.bin still run.

If I try to exit the shell, the Docker daemon hangs. I have to kill -9 the docker commands and restart the docker-machine in order to regain control of the container.

investigation

There may be a bug in unoconv (see https://github.com/dagwieers/unoconv/issues/189) but irrespective of that , I think it's not a good idea to have mfr server running as PID 1: The lifecycle of other processes that we may want to run on the container won't be started or shutdown gracefully by an init process.

using a process supervisor as PID1 is a better approach.

Even if a MFR is intended to be the only process running, it's more portable to use the logging/lifecycle/process control features of a process manager than rely on docker for this.

workaround

• immediate: before exiting the shell, kill the soffice.bin manually
• proper: re-engineer the Dockerfile so a process manager (e.g: supervisord or mozilla circus) is used as PID 1

[felliott]

Thanks, @rija! A bit of background: the unoconv container has been troublesome for us, frequently locking up and very hard to upgrade. @TomBaxter was working on trying to upgrade it for us, and I think he ran into this issue before. Tom, do you mind taking a look at this PR and see if it fixes some of the issues we were encountering?

Cheers, @felliott

[TomBaxter]

Hello @rija , it may be a bit before I can look into this in detail. In the meantime, let me give you the URL for our production unoconv docker container. https://hub.docker.com/r/centerforopenscience/unoconv/ . Hopefully, that gets you where you want to go. If not, I'll get back to this shortly.

[felliott]

Hey @rija,

Sorry for the slow response. The OSF's docker-compose file now has an entry for unoconv. If you bring that up and update MFR to current develop (df525f81), you should be able to render docx files in local development. In addition, the v0.22.0 release added a SIGTERM handler, so you shouldn't have to wait 10 seconds for docker to kill the process after issuing a ^C anymore. I'm going to close this for now, but if you run into any trouble, feel free to reopen it.

Cheers, @felliott