NichollsGlen

I have some requests: Is it possible to add mover status somewhere in the UI for mover progress? What should I query in a script to see if a move operation is running? Check if age_mover is running or something else? Can you add an option to prioritize large files for move? For 1When checking/rebuilding parity, for example, Dashboard and Main show a quick overview of % complete, speed, and a rough ETA. The parity % completion is also exposed in the bottom left of the UI as well (where it normally says "Array started"). Basically, there are multiple places to see not only parity check is running, but also progress and status (running, paused, etc.). I'd love to have mover activity similarly exposed in the UI. Ideally, UI elements would be identical to parity, but these are the specific attributes I would like exposed somewhere: % complete/file move progress mover speed ETA Maybe a flag/warning if things are moving unusually slow I understand that with the mixture of HDD/SDD storage, that information would be inherently inaccurate. However, I'm not looking for accuracy; simply exposing the real-time rsync statistics would be helpful. For 2I have a script that pauses heavy IO processes when parity is running that I'd like to expand to the mover process. What should I query for the mover plugin? Is looking for the age_mover process sufficient, or should I run something else? For 3This is purely preference, and I don't have a strong need for it other than clearing data from unRAID cache quickly when mover is triggered. I would like an option for mover to sort based on file size and start with the largest files first. This is to clear space quickly and delay the slowdown of thousands/tens-of-thousands of disparate small files that occur randomly throughout the discovery process. Move files based on minimum size option is almost there. However, it ignores all the small files I would still want moved eventually. Instead, I propose a mover option to prioritize based on file size. My vision is to add two config options: "Prioritize file size" toggle: When false (default): the following is hidden and set to auto/existing file mover behavior When true: unhides/makes the following selectable: "Sort preference" drop-down: auto, or none? (default): existing mover behavior largest to smallest smallest to largest

Can a setting be added to select the desired log level? Notifications in the UI are one thing, and I agree there; i.e., don't interrupt the user unless it actually requires their attention. However, the entire point of a system log is to log activity, both successes and failures. Without context, determining how or why something failed is already hard enough. Assuming the logging frequency is appropriate for the selected level, I don't see an issue with periodically emitting successes. Hundreds/thousands of logs in a short timeframe is spam, not a single message every X minutes. IMO, the previous behavior was just good practice. I thought this plugin had a bug after an uptick in SSD writes since I wasn't seeing the RAM-disk messages. Yes, I know, I missed the changelog note about the new log behavior. But the plugin literally only logged 1 line every X minutes; they were never "spammy", so the immediate assumption was that something more substantive was changed because that disappeared. That one line was the validation that yes, the plugin was working and to look elsewhere for SSD writes. This is my $.02 now that I'm here. It's not often I have to read system logs, but I'm always thankful for verbosity when I need to analyze them. They're logs; they're not supposed to be pretty. I'll admit, I don't fully understand the quoted comment because everything else unRAID does is exponentially more verbose in comparison. But I respect the desire, which is why I think it makes sense to expose this as an option in the plugin config.

nvm, sounds like the issue I am seeing is because I have explicit version tags I update manually. This link and other comments provides a solution to handle that as well EDIT: Adding docker image prune -a -f after the docker rmi command in the delete_dangling_images properly deletes the orphaned images as well.

Hmmm, not OP but that doesn't do anything with orphaned images. I have a bunch of orphaned images and the script fails because the command for the dangling images doesn't return anything for docker rmi: docker rmi $(docker images --quiet --filter "dangling=true")

I removed the CA plugin "Prometheus nvidia-smi Exporter" and it appears to have solved the issue as my server has now been up for 18 days. I'm not certain this plugin is the culprit, but it has stayed up longer than it has since installing that plugin. I'll update back if I still see the issues I described above.

Just found out that the only apps that show up in previous apps are the ones that were deleted/no longer present on system. Once they're gone, the previous apps shows everything from my user templates.

I am attempting to re-install all of my docker apps so I can reduce the size of my docker image. However, none of my apps are listed under Apps > Previous Apps. This is based on the following since I wasn't seeing too much traffic there: Essentially, all of my templates are located in /boot/config/plugins/dockerMan/templates-user/ but I only see a couple of those in Apps > Previous Apps. I should note that all of my containers were downloaded through CA. What can I do to get Previous Apps to update with those templates to make my life easier when re-installing them?

Feel free to close this. I found some posts on Nvidia's support that are similar so I'm going to go that route for support as this doesn't seem like an issue with unRAID.

Interesting... I installed all my containers through CA and haven't noticed any issues other than them not showing up there while trying to re-install to reduce the size of my docker image.

@trurl or anyone else know how to get all my templates in /boot/config/plugins/dockerMan/templates-user/ to show up in Previous Apps?

@JPDom1 did you ever find a fix for this? I've been seeing very similar kernel panics every 15 or so days and not quite sure how to fix it.

Seemingly every 15 days, my unRAID server has a hiccup in the middle of the night and the GUI/terminal are inaccessible. When this happens, I have to do a hard reboot and receive no information about what exactly the problem is. I mirrored my syslog to flash and am seeing a kernel panic a couple days ago (on vacation so didn't notice until today). However, I am unable to determine what the problem actually is, so hopefully someone here will understand the logs better. I have attached the logs from July 28th when this happened last. This looks like there's an issue with nvidia-smi, but that's about as far as I've gotten with this. Let me know if there's any other information needed. syslog.txt

Okay perfect, I see those now. Thanks for the tip! Hmmm, so I still don't see most of the templates in Previous Apps that I installed through CA. I see all of my templates (phew) in /boot/config/plugins/dockerMan/templates-user/ , but only a couple of them show up in Apps > Previous Apps... All of them are in Installed Apps but it'd be nice to see them in Previous Apps so I can set all of them up at the same time. Is there a way to import the XML in the Previous Apps or something so they show up there?

Regarding your point about re-installing from the templates in Previous Apps, what do you do if the previous apps doesn't have all the docker containers? For reference, I checked previous apps before attempting to shrink my docker image and noticed that it does not contain any of my current templates for the 20+ containers I have in the Docker tab.

Sounds good, thanks for the guidance! I don't know PHP and the simple changes I tried all caused the script to go haywire, so I ported and modified your script in Python - it can be found at https://github.com/GlenNicholls/unraid_parity_scripter . It uses JSON for the containers to stop when parity is running and containers to start when paused/stopped. I need to add some more stuff to make it generic such that it can be used out of the box in a generic environment, but your suggestions work.