guy2545

Members
  • Posts

    15
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

guy2545's Achievements

Newbie

Newbie (1/14)

3

Reputation

  1. So this is interesting, apparently my Traktarr Docker is basically a super computer and is using >9EB of RAM: I don't even remember installing that much RAM and it seems to be holding the entirety of the internet in memory...
  2. Changing the temp setting (apply) then changing it back worked great for me. Thanks for the great plug-in!
  3. Running my monthly parity check on my system and the system became unresponsive numerous times throughout the check. The GUI and console would stop responding for ~30-60 seconds. I've attached a snip of the call trace below as well as the diagnostics, but it seems whatever core of my FX-8370 was pegged to 100% was the core that showed up in the log as "NMI backtrace for cpu X". Nov 30 04:23:03 Tower kernel: NMI backtrace for cpu 1 Nov 30 04:23:03 Tower kernel: CPU: 1 PID: 7410 Comm: unraidd Tainted: P W O 4.19.56-Unraid #1 Nov 30 04:23:03 Tower kernel: Hardware name: To be filled by O.E.M. To be filled by O.E.M./970 PRO GAMING/AURA, BIOS 0901 11/07/2016 Nov 30 04:23:03 Tower kernel: Call Trace: Nov 30 04:23:03 Tower kernel: <IRQ> Nov 30 04:23:03 Tower kernel: dump_stack+0x5d/0x79 Nov 30 04:23:03 Tower kernel: nmi_cpu_backtrace+0x71/0x83 Nov 30 04:23:03 Tower kernel: ? lapic_can_unplug_cpu+0x8e/0x8e Nov 30 04:23:03 Tower kernel: nmi_trigger_cpumask_backtrace+0x57/0xd7 Nov 30 04:23:03 Tower kernel: rcu_dump_cpu_stacks+0x91/0xbb Nov 30 04:23:03 Tower kernel: rcu_check_callbacks+0x28f/0x58e Nov 30 04:23:03 Tower kernel: ? tick_sched_handle.isra.5+0x2f/0x2f Nov 30 04:23:03 Tower kernel: update_process_times+0x23/0x45 Nov 30 04:23:03 Tower kernel: tick_sched_timer+0x36/0x64 Nov 30 04:23:03 Tower kernel: __hrtimer_run_queues+0xb1/0x105 Nov 30 04:23:03 Tower kernel: hrtimer_interrupt+0xf4/0x20d Nov 30 04:23:03 Tower kernel: smp_apic_timer_interrupt+0x79/0x91 Nov 30 04:23:03 Tower kernel: apic_timer_interrupt+0xf/0x20 Nov 30 04:23:03 Tower kernel: </IRQ> The parity check is still jugging along at ~70%. Any thoughts? tower-diagnostics-20191130-2039.zip
  4. Thank you! Both drives are rebuilding currently.
  5. So I fixed the power issue. Both parity drives have shown back up in the array, however they are both marked as disabled. I can see the smart status for both drives from the gui. What is the proper way to re-enable the parity drives now that they have returned? Thanks!
  6. Doing some self diagnostics here. The smart reports for both drives do not indicate any issues. Given that none of the other drivers attached to the LSI-2008 are having issues, I think this narrows it down to one of two possibilities: 1) Power issue to the parity drives 2) Specific damage to the specific SATA break out cables attached to the parity drives. (unlikely) Both of these are easy to rule out as I have additional open SATA ports. I also believe I have additional power options for the drives. Unfortunately I can not explore these possibilities until tomorrow morning as I have pihole (VM) setup as the only DNS server and the wife is actively using the internet. This just shows me I need an additional fail-over pihole setup as a backup. As a side note the system was only direct streaming a show locally at the time this occurred. Forgot to mention the system configuration: AMD FX-8370 on a ASUS 970 Pro Gaming/Aura with 32 GB of DDR3 RAM (Non-ECC) Parity: 2x HGST NAS 4TB Data: 7x WD Red NAS 3TB, 1x WD Red NAS 4tb (25TB Total) Cache: Scandisk 480 480GB SSD Unassigned: 2x Kingston 120GB SSDs GPU: GTX 1060 for Plex (docker) Transcoding Power supply: Name brand bronze level(?) 500W -- Calculators say I maybe pushing it and will be my next upgrade Unraid PRO 6.7.2 (NVIDIA version)
  7. Sitting at my desk minding my own business and I get an email alert telling me one of my parity drives was in an error state. It is suppose to be mounted as SDE, but looking at the log it dropped and was added back as SDO in unassigned devices. So I did the logical thing and first grab the diagnostics listed below. Shut down the server, and checked the power and data cables to the drive. Then boot it back up. When it comes back up, my other parity drive has dropped from the array. However this time it does not show up in unassigned devices. So I take another diagnostics. Every 5-10 minutes it will show back up in the array in the green. However when I click on it to look at the smart status it tells me the drive is not spun up, and of course I can't spin it up. Both these drives are attached to a LSI-2008 flashed in IT mode and connected via a SAS2 to four way SATA breakout cable. None of the other drives on that same cable have any issues. So couple of concerns. Both these drives were purchase from the same vendor at the same time and have been active (~1--2 years) for the same amount of time. My system is now no longer protected (no mission critical data thankfully). So what do you think? Bad drives? Bad controller? Bad luck? Thanks! tower-diagnostics-20190730-2203.zip tower-diagnostics-20190730-2141.zip
  8. Have you ran a memtest yet? Might be unrelated, but when my system would freeze like you are describing I ended up with a bad RAM chip. To test, I ran memtest from the unraid menu for several hours. Once I fixed my RAM issue my up time (knock on wood) was stable. Just rebooted from 70ish days up time to upgrade to 6.7.
  9. Not an expert by any means. But if you did not purposely create a VLAN, I would try to set VLAN to disabled on that screen and see if it will connect then.
  10. So certainly not an expert in this, but I have seen in once or twice before in my server. Could be simply be a bit was flipped during the original write to the parity drives or maybe bit rot? I just made sure all my cable were properly attached and no issues with any HBA cards if you are using them. Once I checked all those things, I just waited to see if the issue appeared again.
  11. I mean, the sticker is not wrong right?
  12. Can you attach your logs for Sonarr/Radarr for after you have downloaded something. That way we can see what is happening and why the files are not being picked up?
  13. Okay so it looks like on the basic level there is a small problem with your mapping of folders to the dockers, and then how you and the programs interact with the folder mappings. I've posted mine below as an example. By no means am I saying you need to match your folder mappings to mine, but just showing how it should work. So lets walk through the problem. Sonarr finds a new show in your wanted list, so it sends the information over to SABnzb (I use NZBget, but the process in the same basically). Think of the information Sonarr sends as basically like a website link. SABnzb gets this link, sees that it cames from Sonarr and identifies it as a TV Show, so it starts downloading it. So here is where folder mappings within the programs (Sonarr, Radarr, etc.) the dockers are running and what they are initialized with from the same screenshots you showed here. In my setup, NZBget (your SABnzb) is set within the actual program to start downloading to: /downloads/incomplete which is mapped to /mnt/user/downloads/incomplete on the actual UNraid array. Once it finishes downloading NZBget is set to extract and move the file to: /downloads/completed/tv-shows which is mapped to /mnt/user/downloads/completed/tv-shows on the UNraid array. When NZBget finishes downloading the TV show Sonarr sent to it, it will then send a link back to Sonarr saying the recently downloaded file it located: /downloads/completed/tv-shows/WhateverShowJustDownloaded/ which is mapped to /mnt/user/downloads/completed/tv-show/WhateverShowJustDownloaded/ Set with in Sonarr is the same mapping. So Sonarr knows that recently downloaded TV shows will be in /downloads/completed/tv-shows/WhateverShowJustDownloaded/ Then it can start its magic of moving the tv-show to where I store my media, which is mapped within Sonarr to: /tv which equates to /mnt/user/tv-shows/ on my UNraid array. The same thing happens with Radarr, and it doesn't matter whether the file is downloaded with NZBget (SABnzb) or Deluge. The only exception in my setup is that Deluge downloads to /data and NZBget downloads to /downloads. Both folder mappings point to the same location on the UNraid array. So I initialized both my Sonarr and Radarr dockers with both /data and /downloads, both pointing to the same spot on the array. It has worked perfectly fine since I've set it up, and I am really just to lazy to go back to make it all the same. I think this may have been where some of your problems stem from, and hopefully this points you in the right direction. Folder Mappings: Deluge: /data <--> /mnt/user/Downloads/ /config <--> /mnt/user/appdata/binhex-delugevpn Sonarr: /tv <--> /mnt/user/TV-Shows/ /downloads <--> /mnt/user/Downloads/ Radarr: /movies <--> /mnt/user/Movies/ /data <--> /mnt/user/Downloads/ /config <--> /mnt/user/appdata/radarr /downloads <--> /mnt/user/Downloads/ NZBget: /downloads <--> /mnt/user/Downloads/ /config <--> /mnt/user/appdata/nzbget
  14. Can you post a screen shot of your folder mappings for all the dockers? Just went through some of this with my system.