CountryBoy_71

Interestingly enough, after I posted this, I also noticed that for some reason I had a 'data' folder going to the cache pool (cache to array) which was essentially just my timemachine backups...a good reason to be up to nearly 13M writes, I suppose. I had planned on moving everything back to the onboard SATA ports. The HBA was because my previous board didn't have enough room. Now, with 6 ports plus two m.2, the HBA isn't needed. I will say though, that the cache pool drives were the only ones to ever be affected. I've read that ZFS pools have an option for trim, is this where I should be turning it on or through the system settings?

Hoping for some assistance here. In my setup (6.12.14), I have a two-drive zfs cache pool, both are SSD's. These drives house the appdata (plex, arr's, etc) and I back that up to a zfs backup drive (just to be safe). Every couple of months I will get a warning about the cache pool and one of the drives is in a degraded state. I replace the drive and 2-3 months later, the other one will go. Has anyone encountered this kind of issue and if so, was there anything you did to fix it? I can't imagine that having to replace an ssd every couple of months is a normal thing! Diagnostics are attached. casatower-diagnostics-20250118-0542.zip

nothing at all logged during the update process.

Have a resolution...in part. After posting and reading some comments I started wondering if something got messed up a few months ago when I replaced a single drive in my two-drive zfs cache pool. Going with that I replaced both drives, removed the cache, re-created it and got everything back in place. Now, it seems as though the updates are completing as they should, however, the problem I am still having is that the first container (or array, if I shut it down) takes an extremely long time to complete...this is where the delays in updating are occurring. Subsequent containers don't seem to take as long, always the first. Is there anything or anywhere to check and see why it would take such a long time to shut a container down?

I've been providing and contributing to another post, listed below, in which I was having issues updating containers. Using CA update process would fail (even though it indicated complete). I tried changing the timeout to various timing's but only with intermittent success. I then moved to manually stopping containers, applying updates and restarting...this also worked intermittently and yesterday, while attempting some updates, I went to stop a container and the system kicked out an 'execution error' and froze causing me to hard reboot. This happened a second time, after the restart, but this time it didn't freeze the system. While I initially thought this was a CA issue, it appears to me (though I am no expert) that the problem perhaps lies within Docker as it doesn't appear as though things are shutting down correctly. My last thought is to nuke the docker image and reinstall all containers again. While I know the process, is 'normally' pretty easy, the worry is that if its not the image that's causing the issue, then I would have problems trying to re-install all my containers! At Mod's request, I am creating this post and including diagnostics in the hope that someone is able to take a look and see if there's anything there to indicate that my docker image may in fact be corrupt. Thank you and here is the link to the post I referred to above. https://forums.unraid.net/topic/146853-docker-containers-not-updating/page/2/#comment-1457830 casatower-diagnostics-20240827-0814.zip

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.

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; Downloading, extracting took a bit over 2 minutes, for a ~200mb file. Stopping the container error'd out (with no further information)...this was a new issue not previously seen. The rest of the process proceeded but did not complete. 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?

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.

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

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.

So I've seen many posts about this issue but as of yet, have not been able to solve the issue. My problem, which suddenly appeared a couple of months ago, is that certain app updates (generally over 200mb) are very slow to download, go through the extract and install process only to reappear un-updated. I have tried updating both from the CA page and also, force update through the docker page. Both net the same failed result. Today, while experimenting, I removed one of the problem apps (jellyfin) and its image and then re-installed. This worked, but took an extremely long time to complete. One solution suggested that the appdata was being stored on the array instead of a cache but I don't believe that to be the case with mine but maybe I am missing it? vdisk location; /mnt/user/system/docker/docker.img appdata storage location; /mnt/user/appdata/ casatower-diagnostics-20240707-1312.zip

I hope that I'm not 'beating a...' but thought maybe this question belonged here instead of the main UR topics. I was thinking this as, for me, the issue seems to have popped up since the last CA update (2024.05.03)...and I was and still am running 6.12.10, before and after the issues. The main question I had was, has anybody correlated the issue to the CA and its latest update? I know that this issue as popped up over the months/years. This morning, NetData had the same issue, again. I know others have stated the threshold seemed to be around the 200MB for it being successful or not. NetData was 135MB today. At the risk of sounding completely 'newb', is there a method to manually download, decompress and update? While the containers I listed aren't of huge importance, right now, some others that I use frequently (Plex) will eventually need to be updated.

Hi F1Spain, Thanks for the information...I am wondering, if that is the case, is there any way to manually download and extract...in effect, manually updating these? Right now, it's not a huge deal for me as the two that aren't updating are rarely used but I know, soon, ones I do will have an update and I'm sure they'll be over to 200 mark!

Just wanted to bump this conversation and see if anyone else is/was having this issue recently and found a solution or root cause? In the last couple of days, while trying to update some containers through the 'action center', all seems to proceed as usual, albeit much slower than before, but once done, the update persists and doesn't actually get updated. The two specifically that I am struggling with right now are; Jellyfin and Jellyseer. I did have a couple of others but repeated attempts got it to go and one (netdata), I was able to update from within docker itself. I am running 6.12.10, the 'action center' did have an update last week and the only other thing I have changed was swapped out a cache pool drive, though, everything is working as I'd expect.

Just resurrecting this conversation for a moment. I know I can 'simply' increase the size, however, I also know it isn't necessarily the right way. I have a total of 9 images, which are taking up a total of 15gb. I have my suspicions on the culprit but wanted to find out for sure. I grabbed and ran the script in this video but it is not showing me one of the important sections..."List of docker volumes, the container which they are connected to their size". I will note that I am running UR, v.6.12.8. and, it should also be noted that I am running with datasets (ZFS), which I suspect is causing the problem...