It does look to me like the issue is timeout related, they all appear to fail with a similar error:

 

 

Googling "not continuing with pull after error context canceled", I found similar errors for other docker apps where they mentioned the pull is timing out, and that it can happen especially with larger images, which looks like the problem here also, I'll mention this to LT to see if it helps.

 

 

Don't the significance of this, but when I update syncthing from CLI

docker image pull lscr.io/linuxserver/syncthing

The pull completed successfully, but ended orphaning image

 

Hello,

 

No unraid UI / docker expert, but i'd guess it's orphaned in the tense that it is not currently used by any stopped or running container. At the moment of this capture, your container used an older image, although a newer might be available (and actually downloaded)

 

But still orphaned in the way that it's not attached to any actual container.

 

There are pruning commands in docker that are quite broad, or more specific ones as well, I don't know if Unraid has some mechanisms to clean orphaned images every once in a while, I guess you can also remove them through the GUI

Most of my containers will not update.  Here is screen shot after doing "update all".  Only RoonServer updates correctly.  All the rest still say "update ready".

 

 

57 minutes ago, xrqp said:

Most of my containers will not update.

Do they update if you do a manual docker pull, like other users mentioned a few posts above?

In my case, I am beginning to wonder if it is a file transfer (or NIC) problem and not a Docker problem.

I say this because I notice when moving files (~2gb) to this same unRaid server it also would stall and then eventually complete.

I tried the same files on a second unRaid server and the transfer went fine.

I do have Cache setup (ZFS raid1) on both, but they do have different motherboards

 

I will try a usb NIC to see if it makes any difference and report back

Switching to USB NIC made no difference.

Transferring 2gb file from windows to unRaid1 stalls at about 1.5gb, then says can't complete, but if skip the offending file it ends up being transferred anyway

Transferring from second unRaid server to unRaid1 server had same result - stalls and finally completes

However, a transfer from unRaid1 (server with docker problem) to unRaid2 completes w/o problem.

 

A quick search shows that others may be having similar issues

https://forums.unraid.net/topic/151968-issues-transferring-larger-files-from-windows-pc-to-unraid/

 

34 minutes ago, uglytuna said:

Transferring 2gb file from windows to unRaid1 stalls at about 1.5gb, then says can't complete, but if skip the offending file it ends up being transferred anyway

Recommend creating a new thread for that and posting the diagnostics after a failed copy, it may be unrelated to the docker update issue, and even if it's not, it would be better discussed on a dedicated thread.

Just wanted to let others know that, in my case, the issue was a bad SSD in my cache.

Even though extended SMART test didn't show any problems switching out cache pool SSDs fixed problem for me

On 8/21/2024 at 2:48 AM, JorgeB said:

Do they update if you do a manual docker pull, like other users mentioned a few posts above?

How do I do a "manual docker pull"? 

Do I uninstall the container, then Go to the Apps tab in the Unraid GUI, then Go to the Previous Apps section, then reinstall?

6 hours ago, xrqp said:

How do I do a "manual docker pull"? 

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

 

 

On 8/24/2024 at 2:09 AM, JorgeB said:

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

 

 

This is the first time I used the shell.  For the first words, I tried both "docker pull" and "docker image pull" and got same error response: 

 

 

at https://hub.docker.com/r/linuxserver/emby/  it said:

 

Am I doing it right?

8 hours ago, xrqp said:

This is the first time I used the shell.  For the first words, I tried both "docker pull" and "docker image pull" and got same error response:

The address may not be complete, click on the docker image, then edit, and make sure you are using the full repository path, e.g.:

 

23 hours ago, JorgeB said:

The address may not be complete, click on the docker image, then edit, and make sure you are using the full repository path, e.g.:

 

 

It shows

Edited August 29, 20241 yr by xrqp

2 hours ago, xrqp said:

It shows

Is that the default? I don't have that container, but trying to install it shows:

 

 

try adding lscr.io/

canceled post and redid below.

Edited September 3, 20241 yr by xrqp

On 8/29/2024 at 2:46 AM, JorgeB said:

try adding lscr.io/

I don't remember if my repository was the default.  I changed the container so Repository is "lscr.io/linuxserver/emby" and when I "applied" that setting it started to download the latest showing "lscr.io/linuxserver/emby:latest".  It took a few minutes and appeared to go thru a complete download and update, but when done the emby docker was completely gone from my dockers.

 

I tried to re-install it from "Apps", then "Previous Apps".  It runs a couple minutes then says it cannot find the container locally for "lscr.io/linuxserver/emby:latest".

 

So I guess I need to install a new emby container from scratch.  

Edited September 3, 20241 yr by xrqp

I tried installing a different emby repository - the official one from emby, and I got this error message:

 

Hello all, @xrqp i am not sure it's related to our problem even if symptoms seem to you related, it'd seem it is a throttling issue from docker hub : https://docs.docker.com/docker-hub/download-rate-limit/

 

On our side, I noticed during a slow pull, that the containerd and/or the /usr/bin/dockerd processes are in D state during all the hanging :

 

"uninterruptible sleep", probably related to hanging IO.

 

I'll look into it, processes seem to systematically hang in D state causing Unraid UI hangups, and especially during image pull a whole docker hang and subsequent crash.

For the record, I am continuing examining my situation.

 

I am now sure Docker in itself is not responsible for the performance issues.

 

I have a weird performance issue when writing to disks, be they SSD pool or main array, past a given volume.

 

For example, when copying a 100Gb file from array to array through a rsync with progress, I also monitor cpu / disks through htop,

 

I have a satisfying 150+mbps until 5Gb have been transfered, at which point it comes to a crawn at roughly 1Mbps, with sorts of hiccups.

 

Exact same situation on the SSD pool, initial speeds being higher ofc.

 

When I was monitoring this, this 5gb mark seems to correspond to the vm.dirty ratio of RAM I was using during the test (value was 10, with 48Gb Ram)

 

5gb is available on fresh Unraid startup, if I try to relaunch a transfer right after shutting the previous transfer process, memory seems to not have flushed and I have horrendous performances right after. If I wait for a bit and there is no background process writing to disks using this cache, it can go fast for a bit again.

 

Despite having the exact same symptoms when drives were plugged in the mainboard, I still upgraded my LSI SAS IT card to latest firmware without any improvement (v something.19 to v something.20.0.7)

 

Other than an Unraid specific component displaying incompatibility with my specific hardware, I can't see anything else than the PSU failing in some sort now. I will try finding a spare to test.

Edited September 10, 20241 yr by triskell34

Just to confirm, still getting the same problem on v7b4. Manual pull is still the only reliable way to update and avoid your containers getting orphaned due to update failures, then having to reinstall them and figure out all the config settings again.

Hi all,

 

To follow up on my problem, this whole docker update process fail, was due to the previous SAS controller I used, that had great performances initially, but it's buffer seemed to be a mess. A first baseline of data was good, but as soon as it went over 500mb data exchanged in let's say a minut, it's bandwidth was down to a few kbits/s .

 

Hence the erratic behaviour of any process relying on it.

 

I first tested the disks on motherboard's SATA before changing the SAS controller, it's been now 2 weeks, and the situation is back to normal at last.

 

Some walkthrough on tests might be found in my posts above if someone would need to troubleshoot the issue as well.

Hi,

i have the same issue, i confirm that when you manually pull the image that you can update the docker.

But what is very wierd is that the cpu while downloading/extracting goes crazy on load..

 

I have also an HBA but with a S-ATA controller. I will test if the update works, if i install the SSD directly into the motherboard.
(Only in a few days, i go to vacation)

Are you using Jumbo frames by chance?

 

Is this only with containers that are ghcr.io/xxxx?  Try removing the ghcr.io/ (or lscr.io) from the repository entry on the edit template screen

 

 

Yes -8192MTU

 

Nope, with any repository.

 

It worked flawless until one day 😬 with same setting nothing has changend.