Squid

One problem fixed. Now wait and see what happens

diagnostics would tell or df -h

76% what docker or log

the appdata will be safe and the templates will be already filled out and reinstalled the same way.

I missed that being mentioned. Try this Settings - Docker - Disable the service. Delete the image, re-enable the service Apps, Previous Apps, Check off what you want

Nothing particularly changed on the usage of the log.

Thank you I was hoping that you'd do the diagnostics command before rebooting. Wait for the log to start filling up again, then post a new set of diagnostics

from the terminal, diagnostics It'll get saved to the flash drive in the logs folder. Upload that zip

unRaid's webserver ran out of memory for some reason. Not quite sure why, but you're going to reboot to fix.

Regarding <TemplateURL> If having this entry populated with the URL causes problems for you, then going forward (as of Feb 21) maintainers can manually edit the appropriate xml in their repositories and either change the existing entry or add in <TemplateURL>false</TemplateURL> If the appfeed sees false in that entry, then it will not populate it automatically with the URL of your template. This has the result of if a user deletes a variable, then on the next container update dockerMan will not re-add that variable back into their template. This is a manual only edit, and cannot be done via dockerMan's GUI. If any one starts bugging you about FCP complaining about a missing template URL via FCP, then tell your users to simply ignore that error. Note that any of your users will also either have to reinstall the app from scratch or manually edit their user template to get rid of the existing entry. @Roxedus

Programming Board would be the applicable place, but I'll go ahead and let the feed ignore populating that entry and will post somewhere in there with an entry to add to the template to do this.

OK. So how would this scenario work: User installs template X Sets it up and deletes the applicable config Updates happen and that entry never gets repopulated into the user template Buddy decides for whatever reason to start over again from scratch with their appdata. Deletes the applicable appdata folder, uninstalls the app, then reinstalls from previous apps. Now that particular variable is missing from the template, and the container won't install properly It's basically nothing (1 line of code) to have docker updates ignore a config update if an attribute is present. But I can foresee situations like the above happening. I think what I'll do instead is allow on the template instead a flag to have the appFeed skip populating the TemplateURL which will also fix the problem (but has other caveats), but is probably easier to deal with in the long term.

So you think it would be useful to have something like a "noUpdate" attribute on the applicable <Config> entry so that the system when it updates will ignore that element and not add it in again... @binhex?

Post diagnostics when that happens.

Ah. Feature of unRaid itself. Any update to the container will also bring in any missing ports / variables etc under the assumption that the update brings new features that might require that. I'd recommend that the container is set up to ignore variables that aren't actually filled out. Alternatively, you can disable that feature completely by editing the template within /config/plugins/dockerMan/templates-user and removing the <TemplateURL> entry. (Although at that point FCP will complain, but that can be ignored) Over the years, the updating of the template has proved to be useful as the apps themselves evolve, (ie: webUI entry changes), but it's never going to be a perfect system. Because of the maintainers who did fill out that entry in the first place did it wrong (fully 50% of them), CA's appfeed now handles it and there is no more access to that entry in the webUI anymore.