Plugins tab not loading if docker enabled

[chris9208]

I have recently encountered an odd problem. I can see installed plugins when the array isn't started, or when it is started but docker is disabled. If I enable the docker service the plugins page times out and never shows installed plugins, even if all dockers are stopped. The following error appears in the log:

Quote

Jan 30 23:19:40 Tower nginx: 2022/01/30 23:19:40 [error] 30374#30374: *249517 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.100.51, server: , request: "GET /plugins/dynamix.plugin.manager/include/ShowPlugins.php?check=0 HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "tower", referrer: "http://tower/Plugins"

 

I have added the full diagnostic file below too.

 

Rebooting does not resolve the issue (except the array doesn't auto start so plugins can be accessed but as soon as it, and therefor docker, starts the problem returns).

 

Thanks in advance for any responses

tower-diagnostics-20220130-2322.zip

[trurl]

Maybe it is just one of your containers instead of all of docker to blame. If you don't autostart any of your dockers and just have the array and docker service started, but no containers actually running, does it still have the problem?

 

 

Probably unrelated, but your appdata has files on the array.

 

[chris9208]

Hi, thanks for your response.

 

I have stopped any containers auto starting and no change. I have attached an updated diagnostic incase it is of any use.

 

I had noticed about some appdata being on the array but that has been the case for some time and all the containers seem to function as expected. The appdata share is set to prefer and mover does nothing to the files on the array. Also, they seem to be copies and no file only exists on the array within the appdata share.

tower-diagnostics-20220131-0159.zip

[chris9208]

So I managed to sort the appdata on array issue, just some old duplicate files. Unfortunately that hasn't resolved the issue.

 

I have also discovered that I can't ping outside my LAN when docker is active but can when it is not. Also, I can not ping external or access the plugins tab regardless of whether docker is active if IPv6 is enabled in network settings or not. Having IPv4 only s not a problem for me at all currently and is how I have been configured since first set up, just adding information incase its useful.

 

Hope this helps find a solution.

 

edit: I can ping outside then LAN if I specify an IPv4 address, but if I ping google.com its appears to use IPv6 and fail. 

Quote

root@Tower:~# ping 1.1.1.1

PING 1.1.1.1 (1.1.1.1) 56(84) bytes of data.

64 bytes from 1.1.1.1: icmp_seq=1 ttl=59 time=6.48 ms

64 bytes from 1.1.1.1: icmp_seq=2 ttl=59 time=6.39 ms

64 bytes from 1.1.1.1: icmp_seq=3 ttl=59 time=5.82 ms

64 bytes from 1.1.1.1: icmp_seq=4 ttl=59 time=6.38 ms

64 bytes from 1.1.1.1: icmp_seq=5 ttl=59 time=6.44 ms

^C

--- 1.1.1.1 ping statistics ---

5 packets transmitted, 5 received, 0% packet loss, time 4004ms

rtt min/avg/max/mdev = 5.822/6.302/6.478/0.242 ms

root@Tower:~# ping google.com

PING google.com(lhr25s33-in-x0e.1e100.net (2a00:1450:4009:81f::200e)) 56 data bytes

^C

--- google.com ping statistics ---

7 packets transmitted, 0 received, 100% packet loss, time 6135ms

 

If I delete all IPv6 routes (apart from the default route) on the network page then I can access the plugin page with docker enabled. The rule seem to recreated on reboot and bring the problem back.

Additionally, deleting the IPv6 routes seems to disable any ping by domain name, but the sites can still be pinged at their IPv4 address

Quote

root@Tower:~# ping 140.82.121.4

PING 140.82.121.4 (140.82.121.4) 56(84) bytes of data.

64 bytes from 140.82.121.4: icmp_seq=1 ttl=53 time=22.3 ms

64 bytes from 140.82.121.4: icmp_seq=2 ttl=53 time=23.0 ms

64 bytes from 140.82.121.4: icmp_seq=3 ttl=53 time=23.1 ms

64 bytes from 140.82.121.4: icmp_seq=4 ttl=53 time=23.5 ms

64 bytes from 140.82.121.4: icmp_seq=5 ttl=53 time=23.1 ms

64 bytes from 140.82.121.4: icmp_seq=6 ttl=53 time=23.5 ms

64 bytes from 140.82.121.4: icmp_seq=7 ttl=53 time=23.1 ms

64 bytes from 140.82.121.4: icmp_seq=8 ttl=53 time=23.8 ms

64 bytes from 140.82.121.4: icmp_seq=9 ttl=53 time=23.2 ms

^C

--- 140.82.121.4 ping statistics ---

9 packets transmitted, 9 received, 0% packet loss, time 8003ms

rtt min/avg/max/mdev = 22.309/23.182/23.777/0.388 ms

root@Tower:~# ping github.com

ping: github.com: Name or service not known

 

edit 2: This seems to be the only route that needs be be deleted to cause the above behaviour

I do not have to remove this route if I disable docker, and do not have to disable docker if I remove this route.

 

I am completely out of my depth here and this may be normal behaviour and not helpful, just adding any info I can find.

 

Thanks again

Edited February 6, 2022 by chris9208

[Squid]

This doesn't make a lot of sense to me, and short of assigning static DNS addresses (recommended anyways) shouldn't have any affect since you're pinging IP addresses.

 

Perhaps @bonienl has insight (I've never seen anyone post this sort of behaviour before)

[chris9208]

I have tried assigning static IPs and no help unfortunately. Appreciate your time looking