Docker "stop timeout" option not applying on server reboot

[Unstoppable]

Hi all,

 

I found a little issue regarding the Docker "stop timeout" setting. When rebooting/shutting down the server, it seems that this value is ignored by Unraid and it just uses the default 10 seconds. I'd really like it if the configured stop timeout was respected, also during reboot/shutdown. To be clear, the timeout is working when using the GUI or CLI to stop the container, just not on shutdown.

 

For some context, I was working on a Docker container that allows the (appdata) folders of high disk IO containers to be moved to RAM and be synced periodically back to disk. This was inspired by this topic: 

Problem is, on shutdown I would like to wait a period of time to make sure all containers have stopped (except mine) before executing the final sync to disk. This does work, as long as I do not wait longer than 10 seconds minus some time for the syncing. I'd like to be able to wait longer however, to be on the safe side.

 

Is the current behaviour regarding the stop timeout on shutdown as intended? Or is it a bug? In case of the former, I suppose my only option is to use scripts to do what I want. But I'd really like to not have to use those.

 

EDIT: Forgot to add, I'm currently using the latest version of Unraid: 6.11.5

Edited December 3, 2022 by Unstoppable

[TexasUnraid]

Are you using a "stop" script like in that guide?

 

I do not have any issues when using that, it stops all the dockers and then syncs the ramdisk back to appdata before the rest of the shutdown process is started.

 

I did have to extend the total shutdown timeout for the server some to make sure everything finished (think the setting is settings > disk settings > shutdown timeout).

 

That said I have not paid attention to is all the dockers are shut down nicely, never really noticed that one.

[Unstoppable]

19 hours ago, TexasUnraid said:

Are you using a "stop" script like in that guide?

 

I do not have any issues when using that, it stops all the dockers and then syncs the ramdisk back to appdata before the rest of the shutdown process is started.

 

I did have to extend the total shutdown timeout for the server some to make sure everything finished (think the setting is settings > disk settings > shutdown timeout).

 

That said I have not paid attention to is all the dockers are shut down nicely, never really noticed that one.

 

Thanks for your reply! I'm not using the stop script from that guide currently, I'd like my Docker container to be the "complete" solution if possible. Which would be possible, if the docker stop timeout was used during shutdown...

 

I didn't know about the shutdown timeout under disk settings however! But from what I can see, I don't think it'll do what I want as it's already set to 90 seconds. My docker container gets killed after 10 seconds after a stop command issued via rebooting / stopping docker (which happens pretty much instantly). I'll try extending the shutdown timer a bit, and see if it helps.

 

You can see that a container is killed too soon by not having it auto-start btw. It'll show you an exit code of 137 and logs may be missing entries.

Edited December 4, 2022 by Unstoppable

[Squid]

Thanks.  I haven't confirmed the bug, but do see a couple of references in the coding where the user set timeout isn't being honored and in some future version of the OS this will get fixed

[Unstoppable]

39 minutes ago, Squid said:

Thanks.  I haven't confirmed the bug, but do see a couple of references in the coding where the user set timeout isn't being honored and in some future version of the OS this will get fixed

 

Nice! That'd be great  If I can help in any way, such as confirming the bug, I'd be glad to help. Like sharing the code of my project, or a simplified version regarding the shutdown sequence only.

[Squid]

5 minutes ago, Unstoppable said:

That'd be great

It's listed now on an internal bug report, but there's also currently major coding changes happening on the WebUI and the major plugins so it also may get lost in the shuffle for a bit.

[Unstoppable]

On 12/4/2022 at 3:07 PM, Squid said:

It's listed now on an internal bug report, but there's also currently major coding changes happening on the WebUI and the major plugins so it also may get lost in the shuffle for a bit.

 

Well, as long as it doesn't get lost permanently, it's fine with me! So thank you  looking forward to the fix.

 

For now I managed to make things work while remaining within the 10 second time limit. At least, based on a few quick tests. So it should be good for now.