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

[martinpub]

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]

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]

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]

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

[martinpub]

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]

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]

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!