6.11.5 docker icons come and go (page refresh)

Icons once they are downloaded once should never attempt to download again.

 

You would need to post your diagnostics after the following happens:

 

- Icons are present, and then after a refresh the icons disappear, ideally without a reboot happening in between

 

 

Squid,

 

Diags attached. 

 

No reboot in 24 hours and it's happened dozens of times since yesterday and a few times this morning.  Happens every time without fail.  I can refresh the dashboard and I'll go from icons present to icons not; consistently.

 

Thanks

semperfi-diagnostics-20230101-0723.zip

df in diagnostics didn't work for some reason.

 

What do you get from command line with this?

df -h

 

Thanks for looking at this trurl, here you go;

 

 

Are the containers in question all being managed via compose manager?

I had one container enabled using compose.  I've deleted it since it didn't give me the desired outcome (a while back).  It was a gluetunVPN (2).  But like I said, it's gone.  

 

The others are all built using unraid templates.

Day two and a little self healing is happening all on it's own.  Some icons are returning or I should say remain persistent on every refresh.

 

Unable to understand why or how.  To summarize, instead of all icons going away on a refresh; only some disappear.

 

I might have to wait this out?  I'll repost tomorrow with an update.

 

The icons are saved within the docker image.  Once they are downloaded they should never get re-downloaded.

 

The only thing that pops into my mind regarding this is that you can try to recreate the docker image.  Should be mostly painless

 

Gotya.  If I remember correctly, if you delete your docker image, you an restore all your containers simple by pulling the docker template from the docker tab yes?  All my settings\options should remain within the template, I just have to initiate and walk away.

 

I'll get back to you when I do this.  Probably tomorrow sometime, right now I have other "duties" that call me.  Thanks for looking at this and for the feedback!

On 1/4/2023 at 12:13 AM, gmight said:

If I remember correctly

FAQ linked above already explains.

 

Also wiki:

 

https://wiki.unraid.net/Manual/Docker_Management#Re-Create_the_Docker_image_file

 

https://wiki.unraid.net/Manual/Docker_Management#Re-Installing_Docker_Applications

On 1/1/2023 at 2:21 PM, gmight said:

I had one container enabled using compose.  I've deleted it since it didn't give me the desired outcome (a while back).  It was a gluetunVPN (2).  But like I said, it's gone.  

 

The others are all built using unraid templates.

Is the compose manager plugin installed? If it is check its settings page and make sure the "Patch UI" setting in disabled.

Ah dude - that's a wrap.  So I do have compose installed and not only do you have to disable "patch unraid WebUI" setting, but you also must "unpatch" by pressing the button that appears after disabling the feature.

 

That cleared the problem up!  Great call brother, got my icons to stabilize without killing the docker image, I was dreading that.  I'm glad you called it out before I started down that path.

 

Well done and thanks - this is now resolved.

Changed Status to Solved

Changed Priority to Other

Interesting so there may be a bug with the compose plugin gui patch on 6.11

Edited January 8, 2023 by primeval_god

For containers that installed by unraid templates, you can check the following items:

• whether your browser can get file from url of the icon file. (You can use develop tool of browser to get this url.)
• whether icon file exists in '/usr/local/emhttp/state/plugins/dynamix.docker.manager/images/'(icon file name is 'container name-icon')
• whether icon file exists in '/var/local/emhttp/plugins/dynamix.docker.manager/images/'.
• whether icon file in '/var/local/emhttp/plugins/dynamix.docker.manager/images/' is broken.
• whether icon file exists in '/var/lib/docker/unraid/images/'.
• whether the container has label 'net.unraid.docker.icon' and 'net.unraid.docker.managed'
• whether the url of icon file (value of label 'net.unraid.docker.icon') can be accessed by system.

 

Containers that installed with a template are managed by dockerman. I guess:

• Dockerman downloads icon file from url which recorded in label 'net.unraid.docker.icon' of containers. The icon file would be downloaded in '/var/lib/docker/unraid/images/'. Dockerman would not download it again until the file does not exist.
• When the system starts,  system copies it from '/var/lib/docker/unraid/images/' to '/var/local/emhttp/plugins/dynamix.docker.manager/images/' and '/usr/local/emhttp/state/plugins/dynamix.docker.manager/images/'. Config file is renewed at the same time(Route of the config file is '/usr/local/emhttp/state/plugins/dynamix.docker.manager/dockerman.json').
• When browser wants to get icon files, the url of icon file is read from config file and then browser gets icon file from this url.
• At this time,  if the icon file does not exist in  '/usr/local/emhttp/state/plugins/dynamix.docker.manager/images/', file  would be copied from '/var/local/emhttp/plugins/dynamix.docker.manager/images/'. if the file does not exist in '/var/local/emhttp/plugins/dynamix.docker.manager/images/', it would be copied from '/var/lib/docker/unraid/images/'.

 

To recover the icon file, maybe you can delete icon files in all routes above for the certain container. Then the system will download icon file again and renew files in routes above. Before that, make sure that the url could be accessed by system.

 

Edited January 12, 2023 by guobin

The root of this problem was the "patch ui" setting of the compose manager plugin. Among other things it patches it changes the naming scheme of the icons and is apparently buggy on 6.11.5.