bombz Posted February 24 Share Posted February 24 (edited) Hello, Appreciate this post/patch. After every OS update I run through my logs on both servers, Saw this earmarked in the log: root: Fix Common Problems: Warning: Docker Patch Not Installed Which led me here to investigate further. Thank you devs, members, and everyone involved in the UnRaid community! Edited February 25 by bombz Quote Link to comment
iilied Posted February 26 Share Posted February 26 (edited) the server is unable to add any docker correctly. however i try to add any docker app, the name of the docker changes to VNCWebBrowser! i have no idea how to fix it. Edited February 26 by iilied needed an array restart Quote Link to comment
killeriq Posted March 4 Share Posted March 4 Hi, should it fix also the issue that im not able to see available updates as before? Now (not sure from which version) show on 90% dockers " not available" Thanks Quote Link to comment
Squid Posted March 4 Author Share Posted March 4 No. This only changes how docker handles empty paths. If you're seeing "Not Available" then it effectively means that the system can't hit docker hub (or GHCR) to see if there's an update available due to network issues, VPN, etc etc Quote Link to comment
killeriq Posted March 4 Share Posted March 4 4 hours ago, Squid said: No. This only changes how docker handles empty paths. If you're seeing "Not Available" then it effectively means that the system can't hit docker hub (or GHCR) to see if there's an update available due to network issues, VPN, etc etc thanks for point out possible issues, seems is some port issue on VPN, some docker are loading/checking updates and others dont Quote Link to comment
Linguafoeda Posted March 6 Share Posted March 6 6.12.8 broke my plex and handbrake containers, luckily i was able to quickly reinstall from previous apps section on left side of the Apps main tab Quote Link to comment
ElectroBlvd Posted March 10 Share Posted March 10 On 2/18/2024 at 6:23 AM, itimpi said: I would not bother unless you have problems with docker containers which are incorrectly configured and exhibit the symptoms this plugin helps hide. I'm confused. Is this hiding a problem? Or is it fixing/correcting a problem? Quote Link to comment
itimpi Posted March 10 Share Posted March 10 1 minute ago, ElectroBlvd said: I'm confused. Is this hiding a problem? Or is it fixing/correcting a problem? It is hiding errors in the docker templates. If you have templates with the errors containers would stop starting correctly after the Unraid update. These errors used to be ignored so it is re-instating that behaviour. Quote Link to comment
ElectroBlvd Posted March 10 Share Posted March 10 1 minute ago, itimpi said: It is hiding errors in the docker templates. If you have templates with the errors containers would stop starting correctly after the Unraid update. These errors used to be ignored so it is re-instating that behaviour. Why would you want to hide errors instead of fixing them? Quote Link to comment
itimpi Posted March 10 Share Posted March 10 1 minute ago, ElectroBlvd said: Why would you want to hide errors instead of fixing them? There were some examples given earlier in this thread where it was ‘convenient’ to have entries in a template of the type that could trigger an error at run time. I agree fixing the templates is a tidier solution, but as there appear to be lots of frequently used containers whose default templates could trigger this error then the old behaviour was made available as a stop-gap to cut down on the number of people (incorrectly) reporting docker as broken after updating Unraid. There is nothing stopping you from NOT installing the plugin and fixing the templates for any containers you use that then fail. Quote Link to comment
Squid Posted March 10 Author Share Posted March 10 13 minutes ago, ElectroBlvd said: Why would you want to hide errors instead of fixing them? Because it's a very common error that users made in the past. And the result of that error is that everything would have been working perfectly forever, but under 6.12.8 simply updating the container that had the error the user made in the template would result in the container disappearing altogether (not simply stopping / or refusing to start) Far easier to simply have the patch (and all future versions of the OS) to "correct" the template error automatically so that effectively the operation of 6.12.8 and pre 6.12.8 are identical. This process is identical to the philosophy that the entire management of the App ecosystem on Unraid has. Certain errors that are commonly made by the maintainers of the templates themselves are automatically corrected (and flagged) so that the end-user has the least amount of problems. The alternative of not correcting what this patch is doing (and the aforementioned template errors by maintainers) would result in a support nightmare. Quote Link to comment
ElectroBlvd Posted March 10 Share Posted March 10 15 minutes ago, Squid said: Because it's a very common error that users made in the past. And the result of that error is that everything would have been working perfectly forever, but under 6.12.8 simply updating the container that had the error the user made in the template would result in the container disappearing altogether (not simply stopping / or refusing to start) Far easier to simply have the patch (and all future versions of the OS) to "correct" the template error automatically so that effectively the operation of 6.12.8 and pre 6.12.8 are identical. This process is identical to the philosophy that the entire management of the App ecosystem on Unraid has. Certain errors that are commonly made by the maintainers of the templates themselves are automatically corrected (and flagged) so that the end-user has the least amount of problems. The alternative of not correcting what this patch is doing (and the aforementioned template errors by maintainers) would result in a support nightmare. Ok, so this patch IS correcting a problem and not just hiding a problem....? The other person is saying its just hiding it while you're saying its correcting it. Quote Link to comment
Squid Posted March 10 Author Share Posted March 10 Depends upon your point of view and boils down to semantics. The patch doesn't fix any bug or anything like that. It's restoring the behaviour that everyone is used to. It "corrects" how the user set up their template to ignore what docker now calls an error (fatal), by skipping over the offending path. On the other POV, it's hiding the template error by skipping over the offending path. As @itimpi states, if you don't want this plugin, then don't install it. But, every future release of the OS has this patch included anyways, so it's basically irrelevant anyways. Quote Link to comment
ElectroBlvd Posted March 10 Share Posted March 10 6 hours ago, Squid said: Depends upon your point of view and boils down to semantics. The patch doesn't fix any bug or anything like that. It's restoring the behaviour that everyone is used to. It "corrects" how the user set up their template to ignore what docker now calls an error (fatal), by skipping over the offending path. On the other POV, it's hiding the template error by skipping over the offending path. As @itimpi states, if you don't want this plugin, then don't install it. But, every future release of the OS has this patch included anyways, so it's basically irrelevant anyways. I see I see. Thanks for explaining that. Makes sense now. Quote Link to comment
user-115 Posted March 13 Share Posted March 13 On 2/21/2024 at 7:58 AM, ich777 said: In my oppinion it‘s up to the maintainer to mark a path as required in the template which is empty to force the user to either specify a path or remove the path from the template. The same applies to devices that may be empty in the template, they should be also be marked by the maintainer from the template as required so that the user is, again, forced to fill it out or remove the device entry. I do agree with that. It's that sometimes the maintainer doesn't factor that in, so it's helpful to have something like this already in the OS. Helpful for the end user, at least. Quote Link to comment
user-115 Posted March 13 Share Posted March 13 On 2/21/2024 at 7:52 AM, itimpi said: Personally I disagree with that as I am not happy with anything that hides genuine errors when they can easily be fixed. I didn't think of it from that perspective, I do agree with that. What I meant was that this patch should be a native part of the OS instead of a third party patch, so there is no error at all. Quote Link to comment
Kilrah Posted March 13 Share Posted March 13 Just now, user-115 said: What I meant was that this patch should be a native part of the OS instead of a third party patch, so there is no error at all. As mentioned that's how it will be in future releases, but in the meantime it's a patch that can be deployed straight away instead of having to wait for a full OS update. Quote Link to comment
thatsthefrickenlightning Posted March 19 Share Posted March 19 Installed as a precaution. Thank you! Quote Link to comment
Squid Posted March 21 Author Share Posted March 21 There seems to be some confusion etc as to what this plugin is actually doing. As I've said, it's not fixing a bug with the OS. Nor is it patching docker itself (and undoing the security updates which they did). In pseudo code, pre 6.12.8 Unraid handled installs and updates to containers like this 1. Loop through all of the paths listed in the user's template 2. Add the appropriate flags / path to the docker run command 3. End loop Because of how many users set up their templates, the above would generate an error if the host path (or container path) was empty on 6.12.8. The revised code is this: 1. Loop through all of the paths listed in the user's template 2. If either the host path or container path is empty, then skip this path 3. Add the appropriate flags / path to the docker run command 4. End loop Actual code snip I'm adding in (and is included in future revs of the OS) is the second and third line of the following: if ($confType == "path") { if ( ! trim($hostConfig) || ! trim($containerConfig) ) continue; $Volumes[] = escapeshellarg($hostConfig).':'.escapeshellarg($containerConfig).':'.escapeshellarg($Mode); This plugin has to remain installed while you're on 6.12.8. Installing it and uninstalling it (with a reboot) will undo the changes it's adding in. Once you upgrade the OS to a later version, the plugin will automatically uninstall itself - IE: there's no need to uninstall it when you upgrade - the system won't even give you the option since it won't even get installed during boot of the next releases of the OS. Quote Link to comment
Linguafoeda Posted March 21 Share Posted March 21 3 hours ago, Squid said: There seems to be some confusion etc as to what this plugin is actually doing. As I've said, it's not fixing a bug with the OS. Nor is it patching docker itself (and undoing the security updates which they did). In pseudo code, pre 6.12.8 Unraid handled installs and updates to containers like this 1. Loop through all of the paths listed in the user's template 2. Add the appropriate flags / path to the docker run command 3. End loop Because of how many users set up their templates, the above would generate an error if the host path (or container path) was empty on 6.12.8. The revised code is this: 1. Loop through all of the paths listed in the user's template 2. If either the host path or container path is empty, then skip this path 3. Add the appropriate flags / path to the docker run command 4. End loop Actual code snip I'm adding in (and is included in future revs of the OS) is the second and third line of the following: if ($confType == "path") { if ( ! trim($hostConfig) || ! trim($containerConfig) ) continue; $Volumes[] = escapeshellarg($hostConfig).':'.escapeshellarg($containerConfig).':'.escapeshellarg($Mode); This plugin has to remain installed while you're on 6.12.8. Installing it and uninstalling it (with a reboot) will undo the changes it's adding in. Once you upgrade the OS to a later version, the plugin will automatically uninstall itself - IE: there's no need to uninstall it when you upgrade - the system won't even give you the option since it won't even get installed during boot of the next releases of the OS. Just to clarify - are you saying that your fix has been incorporated by the Unraid team in future OS updates after 6.12.8 but no current updates (6.12.9 presumably) are out yet so we must use this plugin if we are on latest stable (6.12.8)? Quote Link to comment
JonathanM Posted March 21 Share Posted March 21 7 hours ago, Linguafoeda said: we must use this plugin Or fix the templates by removing blank entries. Quote Link to comment
bombz Posted April 6 Share Posted April 6 On 3/20/2024 at 8:02 PM, Squid said: Once you upgrade the OS to a later version, the plugin will automatically uninstall itself - IE: there's no need to uninstall it when you upgrade - the system won't even give you the option since it won't even get installed during boot of the next releases of the OS. Thanks for this info. Confirmed on (1X) of my instances that the plugin has removed/uninstalled itself from the plugin lists. I will confirm when I have maintenance time to update the OS Thank you devs and community Quote Link to comment
nraygun Posted April 19 Share Posted April 19 I'm on 6.12.8 and I see this in the plugin "Plugin File Install Errors" tab: /boot/config/plugins-error/docker.patch.plg ERROR And an option to delete. What gives? Quote Link to comment
Kilrah Posted April 19 Share Posted April 19 You're probably not on 6.12.8, or have moved away and come back. Quote Link to comment
nraygun Posted April 19 Share Posted April 19 2 hours ago, Kilrah said: You're probably not on 6.12.8, or have moved away and come back. I recently upgraded to 6.12.8 and didn’t move back. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.