search

daisy / pipeline-webui

A Web User Interface for the DAISY Pipeline 2
Other
3 stars 2 forks source link

webui docker container is not succesfully restarted on system restart (Windows) #137

Open martinpub opened 3 years ago

martinpub commented 3 years ago

When using the --restart always Docker option, stopping the container manually before system shutdown/reboot, the webui Docker image is succesfully resumed when Docker is started again. However, when the container is not manually stopped, the following issue prevents the container from being restarted again.

This application is already running (Or delete /run/daisy-pipeline2-webui/play.pid file).

This makes the use of the Pipeline 2 webui cumbersome in a Desktop environment.

Using Docker 20.10.5 on Windows 10 Pro, Version 10.0.19042 version 19042.

bertfrees commented 3 years ago

Hi Martin.

I tried launching the webui using the --restart always option and then restarting the Docker engine (MacOS), and the webui container started successfully. I also tried persisting the database: -v webui-data:/opt/daisy-pipeline2-webui/data, same result.

I'm not sure what is going wrong on your end. It seems like somehow the /run/daisy-pipeline2-webui/play.pid file is present upon start, but how can that be the case, unless that directory is persisted (or Docker is doing something special I don't know about)?

martinpub commented 3 years ago

Thanks for testing @bertfrees. Actually, a regular restart of Docker is able to properly restart the container again, so I have narrowed it down to system restart. I guess my question is why wouldn't a system shutdown/restart on Windows shut down the containers as gracefully as just a Docker shutdown/restart?

bertfrees commented 3 years ago

I have no idea. A container should normally always start with a clean slate.

martinpub commented 2 years ago

I suspect this is due to the webui container receiving a SIGKILL rather than a SIGTERM upon Windows system restart. I get the same result (container exited with 137) if I kill the container directly (SIGKILL), as opposed to stopping it (SIGTERM). Workaround is to instantiate new container afresh instead of resuming after system restart on Windows.

bertfrees commented 2 years ago

Ah, I wasn't aware that containers could be paused. I wonder why Docker does not send a SIGSTOP.

If it sends a SIGKILL indeed, I don't think there is much we can do, except maybe disabling the "This application is already running" error somehow (but I don't know if that is possible).

martinpub commented 2 years ago

Yes, I agree this is not an issue with Pipeline, nor its Docker images, but rather a Docker use question. So I guess we can close this issue. At first I thought extending the grace period between SIGTERM and SIGKILL in Docker for that container, but it seems a shutdown of Windows goes directly to SIGKILL so that didn't solve the issue. Don't know why. Thanks for the attention @bertfrees!