gurulee

So far so good... 48 hours and still stable. I'm monitoring at the dockers level with Uptime Kuma and the HTTP services of unraid Mgmt int and dockers with PRTG. 🤞🙏🙌

That is apparent and agreed. Is there a way to log more debug level? So can someone advise me next steps to narrow the cause of this issue down? Essentially all the HTTP / HTTPS / webui become inaccessible to unraid Mgmt int on br0 and all dockers on br0.4 and br0.5 intermittently for approx 3-5min. All the while I can still ping all of the interfaces during the issue. Issue seems intermittent and no pattern.

The issue just reoccurred at around 3:30pm / 15:30. All webUI connectivity lost to unraid mgmt int (br0)and all my dockers. But I was still able to ping the interfaces and dockers with custom bridge vLAN's static IP's. The issue resolved itself after approx. 3min and the webUI mgmt int of unraid and dockers became accessible again. I looked at my enhanced syslog plugin and this is the only entry around the time of the issue: Sep 10 11:05:13 Tower root: Fix Common Problems: Error: Macvlan and Bridging found ** Ignored Sep 10 11:10:40 Tower kernel: eth0: renamed from vethe9b73b7 Sep 10 11:15:06 Tower webGUI: Successful login user root from 192.168.100.90 Sep 10 11:18:48 Tower kernel: vethb78d931: renamed from eth0 Sep 10 11:19:03 Tower kernel: eth0: renamed from vethd9921c1 Sep 10 12:17:41 Tower emhttpd: spinning down /dev/sdf Sep 10 12:45:53 Tower emhttpd: read SMART /dev/sdf Sep 10 13:06:06 Tower emhttpd: spinning down /dev/sdd Sep 10 13:16:28 Tower emhttpd: spinning down /dev/sdf Sep 10 13:19:08 Tower emhttpd: read SMART /dev/sdd Sep 10 13:54:51 Tower emhttpd: read SMART /dev/sdf Sep 10 13:55:06 Tower emhttpd: spinning down /dev/sdd Sep 10 15:30:46 Tower emhttpd: read SMART /dev/sdd

Thank you! I will report back 48 hours.

Returning to my question as it relates to my issue, should I switch from macvlan to ipvlan even though I am not aware of any macvlan errors and my vLAN's use bond0 ?

Okay, I have completed the upgrade from 6.12.8 to 6.12.13 successfully with no known issues. I will monitor it to see if the issue returns.

I have been holding off due to all the issues I'm reading about in the release notes and with users. But if that has a specific fix for this, then I will plan for it.

I am experiencing a new issue, and as of recent, with dockers on my custom vlan's (br0, br0.4, br0.5, br0.6) become unresponsive. However, I can still ping IP's on any of the networks. But I just cannot get to the web services running on any of them when the issues occurs, including the unraid webUI on br0. No other network changes have occurred and my unraid has been up for 3.5 months so far. The issue occurs when there is heavier network load on them. For example, Plex mobile app downloading content locally to view offline while another docker is performing downloads, or if multiple people are watching Plex. Uptime-Kuma docker webUI also becomes inaccessible during the issue, but when it resolves, it shows docker monitor events stating: 'Knex: Timeout acquiring a connection. The pool is probably full. Are you missing a .transacting(trx) call? Additionally, external PRTG monitors show HTTPS monitors for Plex and other dockers as timing-out. Additionally, I cannot get to unraid mgmt. webUI on br0 when the issue occurs either. ***When the issue is occurring, unraid CPU, RAM, and network utilization is low as well. The issue resolves itself after approx. 3-5min.... I'm on unraid version: 6.12.8 My network config. (not changed in over a year): Two physical eth interfaces (eth0, eth1) with bonding and bridging enabled. Bond0 (eth0, eth1) is connected to Cisco switch using LAG port config. All vLAN's use parent interface bond0 Docker vLAN br0, br0.5, br0.6 use upstream Opnsense firewall for DHCP pool. Docker custom network type: macvlan I do not see any kernel 'call trace' in my enhanced syslog plugin output. Can someone help me narrow this down and/or recommend if I should try switching to Docker network type: ipvlan ?

Thanks! The docker names must be lower case and match the results of the cmd you provided. 👍

Turns out using the container ID is no good since it changes when you update the docker. I tried using the name of the docker as it shows on my dockers page in the webui.

So I already had that in my docker template. What resolved it for me was to use the docker container ID in the monitor instead of the docker name.

What is the purpose of the Docker setup and docker monitoring type in Uptimekuma then?

I successfully setup and tested the docker host in UptimeKuma. But when I add monitors for docker name, they all fail with 'Request failed with status code 404' Any help would be greatly appreciated.

Thank you! This answered my earlier question on the 'jail.d' folder being missing.

Better late than never 😎 Thank you for posting this.