Jump to content

subagon

Members
  • Content Count

    40
  • Joined

  • Last visited

Community Reputation

1 Neutral

About subagon

  • Rank
    Advanced Member

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks, I try putting sonarr on an ip other than the unRaid server's ip. Update: That seems to have fixed it. Only issue was I had to re-ip several dockers off of the unRaid server ip to get sonarr talking to all of them (sabnzbd,deluge,jackett,nzbhydra2). I guess the lesson learned is to give each docker it's own ip and not share it with unRaid.
  2. I've been using pihole running on a raspberry pi for a few months and no problems. I migrated over to this docker but have a problem. My sonarr docker is no longer unable to resolve dns lookups. The sonarr docker is running on 192.168.1.2 (same as the unraid server) and pihole is on 192.168.1.10 (same ip I was using when running on raspberry pi). No other docker is using port 53 or 67. If I shutdown the pihole docker and restart the raspberry pi, sonarr starts resolving dns again. I feel like I'm missing something basic... Ideas?
  3. Been about a week since my last post and no crashes. I'm hoping that's the problem has been fixed. I've made a few changes, so I can't be sure what fixed it. I assume it was either one of the unRAID updates or replacing a failing/dead drive. I have been having a lot of problems with samba on my Mac, but don't think it's related and I'll start another thread for that topic.
  4. Just installed netdata and looking at the options and settings. I wonder how do you display the /proc/mdstat report/plugin? I looked in the conf file but didn't see any reference to mdstat. It does appear that the plugin is installed as part of the netdata package and docker.
  5. Quick update... My system has been somewhat stable since my last post (about a week). During that time I've had a few other issues that may or may not be related to the kernel panics. Fist, I had a drive go bad and had to replace it. I can't say if the drive problem was because of the numerous crashes (unlikely), or if the drive was causing the panics, or unrelated. I've also updated to 6.6.3. I've seen some error messages in the syslog that seem to be related to the age of the motherboard BIOS, so a BIOS update is needed. I'm also having a lot of problems with samba on my Mac desktop. I don't think it's unRAID since my Windows desktop isn't having any samba problems. I'll need to start a new thread because the samba/Mac is becoming unusable. I do see that's it's possible the Mac might be causing the kernel panics. Because of this, I've been unmounting any samba share on the Mac when not in use. Right now I'm in the middle of rebuilding the lost drive from parity so I'm trying to do as little as possible on the system as not to cause a crash.
  6. Thank you for the information. I'll investigate the dockers with custom IPs.
  7. No crash to report since the last post. Since then I have updated to 6.6.2 and kept an open terminal tailing /var/log/syslog. I just saw this from 30 minutes ago. It did not cause a kernel panic/crash but looked like it might provide a clue. Oct 25 13:59:54 asok kernel: WARNING: CPU: 15 PID: 20898 at net/netfilter/nf_conntrack_core.c:763 __nf_conntrack_confirm+0x96/0x4fc Oct 25 13:59:54 asok kernel: Modules linked in: macvlan xt_nat veth xt_CHECKSUM iptable_mangle ipt_REJECT ebtable_filter ebtables ip6table_filter ip6_tables vhost_net tun vhost tap ipt_MASQUERADE iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 iptable_filter ip_tables nf_nat xfs md_mod nct7904 igb i2c_algo_bit sb_edac x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm crct10dif_pclmul crc32_pclmul crc32c_intel ghash_clmulni_intel pcbc aesni_intel aes_x86_64 crypto_simd cryptd ipmi_ssif mpt3sas glue_helper i2c_i801 i2c_core intel_cstate intel_uncore ahci intel_rapl_perf libahci raid_class scsi_transport_sas pcc_cpufreq wmi ipmi_si button [last unloaded: i2c_algo_bit] Oct 25 13:59:54 asok kernel: CPU: 15 PID: 20898 Comm: kworker/15:1 Tainted: G W 4.18.14-unRAID #1 Oct 25 13:59:54 asok kernel: Hardware name: Supermicro X9DRD-7LN4F(-JBOD)/X9DRD-EF/X9DRD-7LN4F, BIOS 3.0 07/09/2013 Oct 25 13:59:54 asok kernel: Workqueue: events macvlan_process_broadcast [macvlan] Oct 25 13:59:54 asok kernel: RIP: 0010:__nf_conntrack_confirm+0x96/0x4fc Oct 25 13:59:54 asok kernel: Code: c1 ed 20 89 2c 24 e8 26 f7 ff ff 8b 54 24 04 89 ef 89 c6 41 89 c5 e8 bc f8 ff ff 84 c0 75 b9 49 8b 86 80 00 00 00 a8 08 74 02 <0f> 0b 4c 89 f7 e8 04 ff ff ff 49 8b 86 80 00 00 00 0f ba e0 09 73 Oct 25 13:59:54 asok kernel: RSP: 0018:ffff88085f443d30 EFLAGS: 00010202 Oct 25 13:59:54 asok kernel: RAX: 0000000000000188 RBX: ffff8801986ede00 RCX: 0000000000000101 Oct 25 13:59:54 asok kernel: RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffffffff81e09070 Oct 25 13:59:54 asok kernel: RBP: 000000000000b1af R08: 00000000c8ff4e01 R09: 0000000000000000 Oct 25 13:59:54 asok kernel: R10: 0000000000000098 R11: 0000000000000001 R12: ffffffff81e8cc80 Oct 25 13:59:54 asok kernel: R13: 000000000000729c R14: ffff8805f75e9a40 R15: ffff8805f75e9a98 Oct 25 13:59:54 asok kernel: FS: 0000000000000000(0000) GS:ffff88085f440000(0000) knlGS:0000000000000000 Oct 25 13:59:54 asok kernel: CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 Oct 25 13:59:54 asok kernel: CR2: 0000153b5c810000 CR3: 0000000001e0a003 CR4: 00000000001606e0 Oct 25 13:59:54 asok kernel: Call Trace: Oct 25 13:59:54 asok kernel: <IRQ> Oct 25 13:59:54 asok kernel: ipv4_confirm+0xaf/0xb7 [nf_conntrack_ipv4] Oct 25 13:59:54 asok kernel: nf_hook_slow+0x37/0x96 Oct 25 13:59:54 asok kernel: ip_local_deliver+0xa7/0xd5 Oct 25 13:59:54 asok kernel: ? inet_del_offload+0x3e/0x3e Oct 25 13:59:54 asok kernel: ip_rcv+0x2dc/0x317 Oct 25 13:59:54 asok kernel: ? ip_local_deliver_finish+0x1aa/0x1aa Oct 25 13:59:54 asok kernel: __netif_receive_skb_core+0x6b2/0x740 Oct 25 13:59:54 asok kernel: ? kmem_cache_free_bulk+0x25b/0x273 Oct 25 13:59:54 asok kernel: process_backlog+0x7e/0x116 Oct 25 13:59:54 asok kernel: net_rx_action+0x10b/0x274 Oct 25 13:59:54 asok kernel: __do_softirq+0xce/0x1c8 Oct 25 13:59:54 asok kernel: do_softirq_own_stack+0x2a/0x40 Oct 25 13:59:54 asok kernel: </IRQ> Oct 25 13:59:54 asok kernel: do_softirq+0x4d/0x59 Oct 25 13:59:54 asok kernel: netif_rx_ni+0x1c/0x22 Oct 25 13:59:54 asok kernel: macvlan_broadcast+0x10f/0x153 [macvlan] Oct 25 13:59:54 asok kernel: ? __switch_to_asm+0x34/0x70 Oct 25 13:59:54 asok kernel: macvlan_process_broadcast+0xd5/0x131 [macvlan] Oct 25 13:59:54 asok kernel: process_one_work+0x16e/0x243 Oct 25 13:59:54 asok kernel: ? cancel_delayed_work_sync+0xa/0xa Oct 25 13:59:54 asok kernel: worker_thread+0x1dc/0x2ac Oct 25 13:59:54 asok kernel: kthread+0x10b/0x113 Oct 25 13:59:54 asok kernel: ? kthread_flush_work_fn+0x9/0x9 Oct 25 13:59:54 asok kernel: ret_from_fork+0x35/0x40 Oct 25 13:59:54 asok kernel: ---[ end trace 1da7a4f5b4f12c5a ]---
  8. Another crash. This time in only 2 days. The parity check from the prior crash didn't finish. I could really use some help.
  9. I feel your pain. I've been having kernel panics since I updated to 6.6.x. Prior versions were rock solid. I can't say if we're having the same issue, but take at look at my console screenshots and see if it's anything like yours.
  10. Five days and another crash.
  11. Well about a week latter and the connection timeouts are back Not sure why they came back, but my cache drive died. don't see how that could have an impact since all my Plex data is stored on a seperate drive (not /appdata).
  12. Started after I updated to 6.6.x. The system runs fine for several days and then is unresponsive. After power cycling the system I have to endure a 2 day parity check. Over the last 2 months I'd guess this has happened 4 times. The console shows a kernel panic (sorry for the poor image).asok-diagnostics-20181012-0708.zip
  13. Not trying to hijack this thread, but I too have been having this problem and maybe it's related. Mine started after I updated to 6.6.x. The system runs fine for several days and then is unresponsive. After power cycling the system I have to endure a 2 day parity check. Over the last 2 months I'd guess this has happend 4 times. The console shows a kernel panic (sorry for the poor image). asok-diagnostics-20181012-0708.zip
  14. Sorry if this is old news, but I haven't seen any news about it... Back in August a new version of Plex was causing problems with connection timeouts. The network connection would go up and down about every 5 minutes and the log would have line after line of "connection Timeout" errors. After contacting Plex support and getting no help I decided to just go ahead and try the current Plex release (1.13.8.5395-10d48da0d) and see if the error was still occuring. It's been a few days and I can report that at least for my system the connection timeout errors are gone.