TexasDave

I have been looking at this issue off and on for several months now. There are two fixes / issues that can cause this. See these threads: CAN NOT WRITE TO ARRAY - INTERMITTENTLY (SOLVED) LOG FILLING WITH "HOST NAME CONFLICT" MESSAGES I had the first issues and corrected it (Shrink the IP range owned by the DHCP server.). I monitored my logs and all seemed well. Then a few weeks later I noticed the issue was back. As it is not a critical issue, I have been messing with it off and on. I believe one of my dockers is triggering this issue in my setup. I attach my logs and diagnostics. The interesting bit is below (I think). I rebooted my server and things ran fine for several days as I had all dockers off. I then turned on Plex (as this is the one I thought might be triggering the issue (but we wanted to watch a movie)) but nothing happened in the log. All was still good. But when the auto-updater ran, and restarted my dockers, the issue manifested itself again. Just curious if anyone can help me narrow this down. Many thanks! Aug 30 09:36:39 Zack-unRAID kernel: microcode: microcode updated early to revision 0x24, date = 2018-01-21 Aug 30 09:36:39 Zack-unRAID kernel: Linux version 4.14.35-unRAID (root@develop64) (gcc version 7.3.0 (GCC)) #1 SMP PREEMPT Thu Apr 19 14:06:21 PDT 2018 Aug 30 09:36:39 Zack-unRAID kernel: Command line: BOOT_IMAGE=/bzimage initrd=/bzroot nomodeset Aug 30 09:36:39 Zack-unRAID kernel: x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' Aug 30 09:36:39 Zack-unRAID kernel: x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' Aug 30 09:36:39 Zack-unRAID kernel: x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' Aug 30 09:36:39 Zack-unRAID kernel: x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 Aug 30 09:36:39 Zack-unRAID kernel: x86/fpu: Enabled xstate features 0x7, context size is 832 bytes, using 'standard' format. Aug 30 09:36:39 Zack-unRAID kernel: e820: BIOS-provided physical RAM map: Aug 30 09:36:39 Zack-unRAID kernel: BIOS-e820: [mem 0x0000000000000000-0x0000000000098bff] usable Aug 30 09:36:39 Zack-unRAID kernel: BIOS-e820: [mem 0x0000000000098c00-0x000000000009ffff] reserved Aug 30 09:36:39 Zack-unRAID kernel: BIOS-e820: [mem 0x00000000000e0000-0x00000000000fffff] reserved Aug 30 09:36:39 Zack-unRAID kernel: BIOS-e820: [mem 0x0000000000100000-0x00000000cd536fff] usable Aug 30 09:36:39 Zack-unRAID kernel: BIOS-e820: [mem 0x00000000cd537000-0x00000000cd53dfff] ACPI NVS . . . . . . Aug 30 12:35:18 Zack-unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): veth1119267: link is not ready Aug 30 12:35:18 Zack-unRAID kernel: docker0: port 13(veth1119267) entered blocking state Aug 30 12:35:18 Zack-unRAID kernel: docker0: port 13(veth1119267) entered forwarding state Aug 30 12:35:18 Zack-unRAID kernel: docker0: port 13(veth1119267) entered disabled state Aug 30 12:35:18 Zack-unRAID kernel: eth0: renamed from veth6f8d175 Aug 30 12:35:18 Zack-unRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth1119267: link becomes ready Aug 30 12:35:18 Zack-unRAID kernel: docker0: port 13(veth1119267) entered blocking state Aug 30 12:35:18 Zack-unRAID kernel: docker0: port 13(veth1119267) entered forwarding state Aug 30 12:35:20 Zack-unRAID avahi-daemon[7109]: Joining mDNS multicast group on interface veth1119267.IPv6 with address fe80::ccc8:7bff:fe12:a8c1. Aug 30 12:35:20 Zack-unRAID avahi-daemon[7109]: New relevant interface veth1119267.IPv6 for mDNS. Aug 30 12:35:20 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::ccc8:7bff:fe12:a8c1 on veth1119267.*. Aug 30 14:46:09 Zack-unRAID kernel: mdcmd (42): spindown 0 Aug 30 16:26:15 Zack-unRAID kernel: mdcmd (43): spindown 2 Aug 30 16:26:17 Zack-unRAID kernel: mdcmd (44): spindown 3 Aug 30 16:26:17 Zack-unRAID kernel: mdcmd (45): spindown 4 Aug 30 16:26:17 Zack-unRAID kernel: mdcmd (46): spindown 5 Aug 30 20:41:44 Zack-unRAID kernel: mdcmd (47): spindown 0 Aug 30 20:41:45 Zack-unRAID kernel: mdcmd (48): spindown 3 Aug 30 20:41:45 Zack-unRAID kernel: mdcmd (49): spindown 4 Aug 30 21:00:17 Zack-unRAID kernel: mdcmd (50): spindown 1 Aug 30 22:20:57 Zack-unRAID kernel: mdcmd (51): spindown 5 Aug 30 23:32:56 Zack-unRAID kernel: mdcmd (52): spindown 2 Aug 30 23:36:36 Zack-unRAID kernel: mdcmd (53): spindown 1 Aug 31 00:00:01 Zack-unRAID Docker Auto Update: Community Applications Docker Autoupdate running Aug 31 00:00:01 Zack-unRAID Plugin Auto Update: Checking for available plugin updates Aug 31 00:00:01 Zack-unRAID Docker Auto Update: Checking for available updates Aug 31 00:00:05 Zack-unRAID Plugin Auto Update: dynamix.system.stats.plg version 2018.08.29a does not meet age requirements to update Aug 31 00:00:05 Zack-unRAID Plugin Auto Update: Community Applications Plugin Auto Update finished Aug 31 00:00:19 Zack-unRAID sSMTP[18184]: Creating SSL connection to host Aug 31 00:00:19 Zack-unRAID sSMTP[18184]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 Aug 31 00:00:21 Zack-unRAID sSMTP[18184]: Sent mail for [email protected] (221 2.0.0 closing connection q21-v6sm3543595wmq.3 - gsmtp) uid=0 username=root outbytes=693 Aug 31 00:00:22 Zack-unRAID Docker Auto Update: Stopping CalibreWeb Aug 31 00:00:22 Zack-unRAID Docker Auto Update: docker stop -t 10 CalibreWeb Aug 31 00:00:32 Zack-unRAID kernel: docker0: port 1(veth14d836d) entered disabled state Aug 31 00:00:32 Zack-unRAID kernel: vethafdcedb: renamed from eth0 Aug 31 00:00:32 Zack-unRAID avahi-daemon[7109]: Interface veth14d836d.IPv6 no longer relevant for mDNS. Aug 31 00:00:32 Zack-unRAID avahi-daemon[7109]: Leaving mDNS multicast group on interface veth14d836d.IPv6 with address fe80::3c8c:cff:fe3b:e5cc. Aug 31 00:00:32 Zack-unRAID kernel: docker0: port 1(veth14d836d) entered disabled state Aug 31 00:00:32 Zack-unRAID kernel: device veth14d836d left promiscuous mode Aug 31 00:00:32 Zack-unRAID kernel: docker0: port 1(veth14d836d) entered disabled state Aug 31 00:00:32 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::3c8c:cff:fe3b:e5cc on veth14d836d. Aug 31 00:00:32 Zack-unRAID Docker Auto Update: Installing Updates for CalibreWeb Aug 31 00:02:09 Zack-unRAID Docker Auto Update: Restarting CalibreWeb Aug 31 00:02:09 Zack-unRAID kernel: docker0: port 1(veth069ef4d) entered blocking state Aug 31 00:02:09 Zack-unRAID kernel: docker0: port 1(veth069ef4d) entered disabled state Aug 31 00:02:09 Zack-unRAID kernel: device veth069ef4d entered promiscuous mode Aug 31 00:02:09 Zack-unRAID kernel: IPv6: ADDRCONF(NETDEV_UP): veth069ef4d: link is not ready Aug 31 00:02:09 Zack-unRAID kernel: eth0: renamed from vetha5a479d Aug 31 00:02:09 Zack-unRAID kernel: IPv6: ADDRCONF(NETDEV_CHANGE): veth069ef4d: link becomes ready Aug 31 00:02:09 Zack-unRAID kernel: docker0: port 1(veth069ef4d) entered blocking state Aug 31 00:02:09 Zack-unRAID kernel: docker0: port 1(veth069ef4d) entered forwarding state Aug 31 00:02:09 Zack-unRAID sSMTP[18651]: Creating SSL connection to host Aug 31 00:02:09 Zack-unRAID sSMTP[18651]: SSL connection using ECDHE-RSA-AES128-GCM-SHA256 Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Joining mDNS multicast group on interface veth069ef4d.IPv6 with address fe80::a013:afff:fe71:1fc5. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: New relevant interface veth069ef4d.IPv6 for mDNS. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::a013:afff:fe71:1fc5 on veth069ef4d.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::ccc8:7bff:fe12:a8c1 on veth1119267. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::64c4:5fff:fe8c:2ea2 on vethd2d6e3a. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::60e0:42ff:fe7b:80dd on vethf61ec24. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::7868:58ff:febb:d786 on vetha52000d. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::2884:93ff:fe00:83e6 on veth75d2346. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::1859:fff:fefc:b7c1 on veth3e43557. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::6c63:eaff:fe7c:2782 on veth685b816. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::30c2:abff:feb4:1491 on veth5e4de85. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::8c9e:d4ff:feb5:5a4d on veth5e3645e. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::a8ad:abff:fe0a:537b on veth832ce0f. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::f81a:a5ff:fe8b:4745 on vethd949b2a. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::a411:aeff:fe19:7cfa on veth2bab9f2. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for 192.168.122.1 on virbr0. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::42:4eff:fe01:7855 on docker0. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for 172.17.0.1 on docker0. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::587d:17ff:fe4d:7827 on br1. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::ac56:eff:fe8a:f6a6 on br0. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for 192.168.1.115 on br0. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Withdrawing address record for fe80::ec4:7aff:fe32:b928 on eth0. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Host name conflict, retrying with Zack-unRAID-2 Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::a013:afff:fe71:1fc5 on veth069ef4d.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::ccc8:7bff:fe12:a8c1 on veth1119267.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::64c4:5fff:fe8c:2ea2 on vethd2d6e3a.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::60e0:42ff:fe7b:80dd on vethf61ec24.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::7868:58ff:febb:d786 on vetha52000d.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::2884:93ff:fe00:83e6 on veth75d2346.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::1859:fff:fefc:b7c1 on veth3e43557.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::6c63:eaff:fe7c:2782 on veth685b816.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::30c2:abff:feb4:1491 on veth5e4de85.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::8c9e:d4ff:feb5:5a4d on veth5e3645e.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::a8ad:abff:fe0a:537b on veth832ce0f.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::f81a:a5ff:fe8b:4745 on vethd949b2a.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::a411:aeff:fe19:7cfa on veth2bab9f2.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for 192.168.122.1 on virbr0.IPv4. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::42:4eff:fe01:7855 on docker0.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for 172.17.0.1 on docker0.IPv4. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::587d:17ff:fe4d:7827 on br1.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::ac56:eff:fe8a:f6a6 on br0.*. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for 192.168.1.115 on br0.IPv4. Aug 31 00:02:10 Zack-unRAID avahi-daemon[7109]: Registering new address record for fe80::ec4:7aff:fe32:b928 on eth0.*. Aug 31 00:02:12 Zack-unRAID sSMTP[18651]: Sent mail for [email protected] (221 2.0.0 closing connection 34-v6sm13553632wra.20 - gsmtp) uid=0 username=root outbytes=617 zack-unraid-diagnostics-20180901-1115.zip

This was fixed by following the advice in this newer thread: Syslog spammed by Avahi

Boom! That was it. It was the first one.... I had some static IPs that were also in the DHCP IP Range. Shrinking the range and doing some cleanup (which I should have done some time ago) seems to have fixed it. Really excited as I learned something new and got rid of a very annoying error. Many thanks!!

Posting diagnostics as requested. Thanks! zack-unraid-diagnostics-20180501-0801.zip

Hi John, Thanks for your reply. The solution you listed is the one I tried with no luck. When I get home, I will post my diagnostics. Thanks!

My syslog is getting spammed by "Avahi". See attached log. I have seen some other threads on this happening. It seems to be an ongoing thing and I would like to address it if possible. It gets caught by Fix Common Problems as it tends to start to fill up my syslog so I get a warning from FCP. Thanks for a pointer to other threads or what I can do on my setup to fix this. This log is shorter (but shows the issue) as I tried one of the solutions in the forum and this required a reboot (but it did not work) Thanks! zack-unraid-syslog-20180429-1111.zip

Howdy, Just received this from "Fix Common Problems".....Call traces found on your server. I am on unRAID 6.4.1 - system information below. Logs attached. I had a quick look and I think it may be something in the docker logs? Thanks for any ideas on where I should look. Thanks! zack-unraid-diagnostics-20180311-1135.zip

@CHBMB - Thanks! I hope all is well for you? Been awhile.... @saarg - Many thanks as well. Both - I have "seen the light" and it is now sorted. I misunderstood what you were trying to say. A bit slower as I get older...Thanks again!

I have tried clearing cache and even installed FireFox and Opera (from scratch) but still do not see that tab.... Not an emergency by any stretch of the imagination.... :-)

When I run TVHeadend on Linux, I see "EPG Grabber Modules" - see attached screenshot. Can I confirm I should be seeing this in the docker? Thanks!!

@stormense - Thank you for the above - I found it very helpful!

I am trying to get TVHeadend to work with a couple of other dockers. There is supposed to be an ability to access "EPG Grabber Modules" as follows: Configuration -> Channel / EPG -> EPG Grabber Modules I just see "EPG Grabber" (not "EPG Grabber Modules"). Is this the same thing? I have tried basic and expert settings. If I was installing this not though a docker, I would do: "apt-get install xmltv-util" Is this built into this docker? Thanks!

I just tried that - no joy. It does work... I can get in when I am on a wired connection. But cannot do so on wireless. This used to work. I doubt it is an unRAID issue but it is strange...I will do soe research on the SuperMicro side of things.

I suppose you have connected the IPMI interface to your router and the router has assigned an IP address for IPMI. From your browser you should be able to reach this IP address, https://<ipaddr> Did you try this? Yes - I did. I have had both working for several years and had not had to touch the cables until 6.4. Both were working fine until I upgraded to 6.4.1. The unRAID console was fine on upgrade but IPMI has stopped. working. I can see it on the network map. Will do some more research and see what I can fid out. Thanks!

I have gotten the "interface not configured" to go away per your suggestions. And I do not need eth1 so I plan on disabling it. And I turned bonding off on eth0 as I am not using eth1. CFCP works fine... But I still have the issue of not being able to get in via the IPMI interface. I can see the IPMI on my router and it is up and working. Just cannot get in. Not a critical issue but it bugs me. Thanks!

"At the top of the network settings it says "Interface is not configured". OK - that makes sense. But both interfaces had been working (one into unRAID and one into the "SuperMicro X10SL7-F" tool / utility) before this... Where does one "configure" the settings? I tried stopping my dockers so I could do it in the unRAID Network settings but cannot do it there. To be clearer - maybe - I have one cable going into the ethernet 0 port (where I access unRAID) and have the other into the IPMI port so I can use the SuperMicro IPMI tool (which now does not work). Do I need to swap cables and do something in the BIOS or the "SuperMicro X10SL7-F" tool / utility?

Just upgraded from 6.4 to 6.4.1. When I upgraded to 6.4 - I had this issue: Now I have a similar issue but with eth1 (which makes sense as I swapped my cables to fix it in the 6.4 upgrade). Any idea why this is happening? Thanks! It shows up when I try to run "Fix Common Issues"

@bonienl - This happened again on the update to 6.4.1 But now it says eh1 is down (which makes sense as I swapped the cables when it first happened). Any reason you know of?

By the way, big thanks for this. Had been using Ubooquity but had been hoping this would get moved to unRAID. Many thanks!!

Doowp! :-) Missed that as it was not required. Sorry about that and thanks!

Just installed this. I had added my Mylar DB but see in the threads above I should delete this. I did this but when I fire up the Web UI for Gazee I get sent right to the unRAID console. See docker template attached. Ideas? Thanks! Document1.txt

Thanks again for your (quick) help....

Boom! That was it. Many thanks @bonienl!!! I will mark this solved in the subject in case others have the issue. Out of curiosity, did I miss something in the upgrade or is this just some weirdness? Why would that happen? I have been on unRAID for several years and never had an issue like this. Thanks!

Happy 2018 to all unRAIDers.... :-) Just upgraded to 6.4.0 - pretty excited. But I am getting the message "interface eth0 is down". See attached. This is manifesting itself in the fact that plugins cannot ping GitHub and my "Application Lists" does not update. So my DNS is messed up. All other systems in the house work fine. No changes on my router. If you look at the attached - is it because my "IPv4 DNS server" setting? I have checked and tried another cable. It is attached. Any help appreciated!

I have been using Sonarr and NZBget for a long time (at least 1-2 years) and they have worked perfectly. All of a sudden I keep ending up with "partial" files only in my media directory. I was wondering if there is a known "pilot error" that could cause this before I post logs. I did start using Hydra and thought that could be it but I went back to not using that and I still have the same issue. Happy to dig in and try to sort it but just wondering if anyone has some initial ideas? Thanks! [RESOLVED: It appears that dropping Hydra and running the indexers directly solves it. Not sure why but will stick with what works....]