On 7/8/2024 at 10:21 PM, Bonzoom said:

I solved my issuse with  Nextcloud and Immich not updating this way:

 

Go to settings

Select docker

Change "Docker Stop Timeout:" to 120 seconds.

 

Issue gone  🙂

Unraid version 6.12.10

Tried this, in my case it doesn't seem to have helped as I still cannot update calibre-web or Handbrake or Mayan-EDMS via the normal route....

I have been having this issue too, I was talking with someone at work who uses docker on a Synology and and he uses watchtower to update his containers. Watchtower checks the images that are installed and automatically downloads shuts down installs and restarts the container. I tried installing it and there's no config needed. The next morning I checked and all the containers that needed an update said they were created 2 hours ago and started 2 hours ago. The only downside is that because of the way unraid tracks when containers are updated they all still show that they need an update. When clicking on update it shows 0b downloaded, restarts the container and then it's good.

Not sure if this was a related issue but due to some unrelated issues my docker.img file got corrupted. Deleting and remaking it and having to redownload the container images everything seems to be working now. Not sure if this will help anyone but it may be worth checking out if there was something happening in the docker.img causing things to not install properly.

19 hours ago, ebro10 said:

Not sure if this was a related issue but due to some unrelated issues my docker.img file got corrupted. Deleting and remaking it and having to redownload the container images everything seems to be working now. Not sure if this will help anyone but it may be worth checking out if there was something happening in the docker.img causing things to not install properly.

I had thought about trying that but my biggest concern was that if it wasn't, or didn't solve, the problem, then I would have one heck-of-a-time re-downloading all the containers again.

10 minutes ago, CountryBoy_71 said:

then I would have one heck-of-a-time re-downloading all the containers again.

This is normally very easy to do using the Apps->Previous Apps->Docker feature which allows you to reinstall the dockers you select with the same settings you previously used.

On 7/10/2024 at 1:30 PM, f1spain said:

Tried this, in my case it doesn't seem to have helped as I still cannot update calibre-web or Handbrake or Mayan-EDMS via the normal route....

Adjusting the "Docker Stop Timeout:" to 120 seconds worked for me (including calibre-web).

1 hour ago, craigmaki09 said:

Adjusting the "Docker Stop Timeout:" to 120 seconds worked for me (including calibre-web).

Thanks for the report, since the default is 10 secs, did you try lower numbers first and it didn't work or did you went straight to 120?

For what it's worth I saw this behavior today for the first time on my 6.12.10 system with both speedtest-tracker and jellyfin dockers and was glad to find this thread.

 

Changing the Docker Stop Timeout: to 120 seconds worked for me. I did not try lower numbers.

 

I noticed the  jellyfin docker update was 291 MB but the speedtest-tracker docker was only 42 MB.

Edited July 17, 20241 yr by dabl

If anyone runs into this, please try with 60 secs first and report here, 10 is the stock default, so 60 is already a big jump, and 120 may cause issues with the default shutdown timeout.

Immich was not completing an update, I increased the time out by 30 seconds and would keep trying. I had to get up to 300 seconds before it completed the time out. It was successful at 300 seconds. I put it back to 10 seconds after the update and everything seems fine. 

34 minutes ago, T_Matz said:

I had to get up to 300 seconds before it completed the time out.

So to confirm, not even 120 secs was enough?

1 hour ago, T_Matz said:

I increased the time out by 30 seconds and would keep trying. I had to get up to 300 seconds before it completed the time out.

also please confirm if the docker image is using the array or an SSD based pool, if you are not sure post the the diags, if anyone else having this issue could also confirm that it may help.

I've tried the '120' fix, worked sporadically.  I'd really like to learn/understand what the underlying issue is since this is a relatively new issue (maybe 4 months now).

 

I'm pretty sure I am on an SSD pool for this but am posting the diags just to be sure.

casatower-diagnostics-20240707-1312.zip

12 minutes ago, CountryBoy_71 said:

I'm pretty sure I am on an SSD pool

Yep, it is.

 

12 minutes ago, CountryBoy_71 said:

I've tried the '120' fix, worked sporadically

Did you try larger values when it still doesn't work with 120?

1 minute ago, JorgeB said:

Yep, it is.

 

Did you try larger values when it still doesn't work with 120?

I have not, yet.  I'll try that tomorrow, if I run into problems.  I didn't want to exceed the 120 as that was way more than the default 10 and didn't want to cause other issues.

Just now, CountryBoy_71 said:

I'll try that tomorrow, if I run into problems.

Please do and report back, another thing you can try, is adding this option to the offending container 'Extra Parameters':

--init

 

On 7/19/2024 at 11:33 AM, JorgeB said:

Please do and report back, another thing you can try, is adding this option to the offending container 'Extra Parameters':

--init

 

So, had a chance to play around a bit this morning since Sonarr had an update.  I left the timeout at 120 and here are my observations when running the update; 

1. Downloading, extracting took a bit over 2 minutes, for a ~200mb file.
2. Stopping the container error'd out (with no further information)...this was a new issue not previously seen.
3. The rest of the process proceeded but did not complete.
4. Went to 'Docker', manually stopped the container and did a 'force update'; successfully updated.

I only had the one update today, so will try moving the timeout value up a bit on the next one.  My lingering question though, from this, is still; while updating the timeout value does seem to work, in some instances, have we figured out what the underlying issue could or may be?  It seems, at least on my system, that the problem originates in the downloading/extracting and stopping of the container, which in turn is causing the timeout/failure.  As myself, and others, have noted, this seems to be a relatively new(er) issue, whether that was from the last UR update, a CA update or a system issue.  Would just be nice to nail it down and I have to assume that if UR required a longer timeout, would the default not be more than 10 seconds?

 

You mentioned adding '--init' to the 'extra parameters' of a container, what does this actually do?

34 minutes ago, CountryBoy_71 said:

have we figured out what the underlying issue could or may be?

Not really, still gathering information, since I cannot reproduce.

 

35 minutes ago, CountryBoy_71 said:

You mentioned adding '--init' to the 'extra parameters' of a container, what does this actually do?

Long shot based on this:

https://donchev.is/post/docker-containers-slow-shutdown/

Timeout set to 10 minutes, and the image pull still stops after 2-3 minutes. Download is taking less than 15 seconds. It never finishes, but moves on to make the container, so I have to ensure I'm using a unique tag with each update or it uses the locally cached image (which isn't up to date for "latest"). If I use one it doesn't have, it grabs it again during the creation and succeeds, but then I have to manually watch for updates. Also attempted update with the container stopped, but same story.

 

IMAGE ID [399967081]: Pulling from imagegenius/immich.
IMAGE ID [84930f30b29f]: Already exists.
...
IMAGE ID [8a8e5eae8ecd]: Already exists.
IMAGE ID [f8804d3fd53d]: Pulling fs layer.Downloading 100% of 370 MB.Download complete.Extracting.Pull complete.
IMAGE ID [afd3fc997c01]: Pulling fs layer.Downloading 100% of 4 KB.Verifying Checksum.Download complete.Extracting.

On 7/19/2024 at 10:23 AM, JorgeB said:

So to confirm, not even 120 secs was enough?

Sorry for the late reply, I was on vacation and did not have access to the internet.  No, 120 seconds was not enough. It was only when I reached 300 seconds that it updated successfully. 

 

On 7/19/2024 at 11:08 AM, JorgeB said:

also please confirm if the docker image is using the array or an SSD based pool, if you are not sure post the the diags, if anyone else having this issue could also confirm that it may help.

I am using an SSD-based pool. The only docker with which I am experiencing this issue is Immich. It happened again with the last update, and I had to increase the timeout to 300 seconds before it updated. Once I increase the time out it successfully updates, I set it back to the default following the update with zero issues with any other dockers.

Thanks for the feedback, still not sure if that setting is really helping, or if it just works after some retries, but will keep investingating

120 works for me too on large images. i have an SSD pool, and gigabit broadband 

12 hours ago, ganey said:

120 works for me too on large images

I don't think that settings really helps, since it works sometimes and not others, even for the same users, but please see here for other possible solution:

https://forums.unraid.net/topic/171402-docker-updates-fail/?do=findComment&comment=1453484

 

Just wanted to add more to the investigation of this issue.  I have my time set to 120 (tried other various timings) but I would still encounter the problem.  While trying different things, I started updating through the docker page.  I would manually stop the application, apply update and restart.  Today, trying the same process, I tried to stop the application and the system took an exceptional long time shutting it down, returned an 'execution error' and then crashed.  Had it happen a second time, after getting the system back up but didn't crash. I was finally able to get all updates completed but each takes a long time to stop, update, and start.

 

I am starting to wonder if its possible that my docker file is corrupt but kind of nervous to wipe it out and try installing fresh.

1 hour ago, CountryBoy_71 said:

I am starting to wonder if its possible that my docker file is corrupt but kind of nervous to wipe it out and try installing fresh.

That is usually a safe procedure, but you can also start a new thread and post the diags since image corruption is usually visible there