fiscalcon

Members
  • Posts

    57
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

Recent Profile Visitors

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

fiscalcon's Achievements

Rookie

Rookie (2/14)

0

Reputation

  1. Config files are clean of that IP address, but I do agree it feels hard coded. That said, my Plex container was working fine and was in host mode. The broken ones were in bridge, so I switched those to host and they start now and appear to be working normally so far. Somehow I found an even simpler solution than swapping IP schemes or increasing the subnet. Thanks to all for bouncing ideas.
  2. Yeah, that is what I am leaning towards at this point. The troubleshooter in me is screaming "whyyyyyyy" though, :-). I'll revert to the old scheme to get things working again. Thanks!
  3. Hello, I recently swapped routers at my home. Found out my ISP does allow the use of your own router, so I wanted more management in that department. While this issue is related to Docker, I do seem to have 1-2 other issues going on that have hampered my troubleshooting. After router swap, my IP scheme changed from 192.168.50.0 to 192.168.1.0 being the network addresses. I found the network settings area in unRaid and that all looks good now. However, when I go to start containers, they appear to be hanging onto the old unRaid IP of 192.168.50.17: root@localhost:# /usr/local/emhttp/plugins/dynamix.docker.manager/scripts/docker run -d --name='NzbDrone' --net='bridge' -e TZ="America/Los_Angeles" -e HOST_OS="Unraid" -p '8888:8989/tcp' -v '/mnt/cache/appdata/nzbdrone/':'/config':'rw' -v '/mnt/cache/appdata/nzbget/downloads/':'/downloads':'rw' -v '/mnt/user/TVShows/':'/tv':'rw' 'needo/nzbdrone' 60b3486d2641a59cd46651b766f413a60a59996cb002505664d934e1b05eb222 /usr/bin/docker: Error response from daemon: driver failed programming external connectivity on endpoint NzbDrone (435d35bf01f088ff58c0bef4d6cc4954b8c9b0a357f04dbbf0491b40d6b39e85): Error starting userland proxy: listen tcp 192.168.50.17:8888: bind: cannot assign requested address. I started doing some recursive greps but I can't find where this IP address is being pulled from. I've done a reboot of unRaid a few times, which is where my other issues come in. Had unRaid lock up on a reboot, or at least my best guess. Upon hard power off, I tried setting up a console, but I can't get the server to display anything. I bring these up in case either of them is valuable in troubleshooting the current situation or anyone asking if I have console working. I've also removed and re-added the containers, including the images. Should I swap to the old IP scheme on my router? I have no hard requirements on that, I just wanted to be able to control some DNS/DHCP/SSH related items. Thanks!
  4. Well I think it was the cat. I was on my computer next to my unRaid, he jumps onto the tower and unRaid starts to shutdown as you can hear all the disks spinning up. Wasn't the first of the month and wasn't 3 in the morning, then off it goes. I've covered the power switch to stop him from hitting it. I had uninstalled the power down script and it was still happening. Thanks for the simple but easily missed checks.
  5. I've been finding my unRAID server off randomly recently. I thought I was running into a hardware issue, but upon each boot I found that a parity check wasn't running. Checking logs, the powerdown script is causing the shutdowns. Thankful nothing more harmful isn't happening, but still want to find the cause. Started on the 27th here: syslog-20160527-144522.txt:May 27 14:43:45 Tower powerdown[28631]: Powerdown initiated syslog-20160529-130606.txt:May 29 13:04:32 Tower powerdown[28291]: Powerdown initiated syslog-20160529-192940.txt:May 29 19:28:29 Tower powerdown[22133]: Powerdown initiated syslog-20160530-142415.txt:May 30 14:22:42 Tower powerdown[15032]: Powerdown initiated syslog-20160531-081411.txt:May 31 08:12:56 Tower powerdown[15053]: Powerdown initiated We haven't had any power outages, at least ones long enough to mess with the microwave/stove clock. I disabled the APC daemon as a test and the power down script shut the server down again today. Looking at the log I only see a start of the APC daemon, not a stop. Checked settings and it was definitely off today during the 8am shutdown. I've attached a syslog from the last time it happened. I could be missing something, but I don't see anywhere that says what is calling the powerdown script. Anything I can add to try and capture what is calling it? Let me know if there is anything more I can provide to assist. syslog-20160531-081411.txt
  6. Have you gone to Settings->Nerd Pack to check that you have those set to install? Maybe this is the first time you have rebooted since Nerd pack was updated to provide individual control over which packages are installed? Nice! Thank you! My server crashed for some reason (still haven't had time to look into why). Thought the plugins not working was caused by it. Even restored to one of my backup configs.
  7. Just updated and rebooted, no issues. Thanks for all the hard work!
  8. I am seeing this issue as well, b14b and b15 (asrock board as well). System specs: CPU - Intel Core i5-4440S Motherboard - ASRock Z97 Extreme6 Desktop Memory - Crucial Ballistix Sport 8GB x 2
  9. Haven't seen this happen on beta12 or higher, :-). Confirming solved for me as well. Feb 27 03:41:57 Tower logger: mover finished Feb 27 03:56:38 Tower kernel: mdcmd (68): spindown 2 Feb 27 03:59:00 Tower kernel: mdcmd (69): spindown 0 Feb 27 03:59:01 Tower kernel: mdcmd (70): spindown 1
  10. Appears resolved for me as well in 14b. I am not coming home to disks spun up. Real test will be if I have disk up in the morning after watching shows/mover runs. But looks promising with others confirming. Thanks to all who helped snipe this one!
  11. my log is showing spindown for drives and the webui is showing them as active. i tried videoing the screen but it's shite quality for some reason. Yea that was exactly what was happening to me. Not being home I couldn't confirm if they were actually up. Suppose I could have done a cd test on the command line. My spin up test worked though, all of them spun down. The next test is normal day use and watch for disks to stay up well after the 15 minute spin down timer. Feb 24 15:17:34 Tower kernel: mdcmd (53): spinup 0 Feb 24 15:17:34 Tower kernel: mdcmd (54): spinup 1 Feb 24 15:17:34 Tower kernel: mdcmd (55): spinup 2 Feb 24 15:17:34 Tower kernel: mdcmd (56): spinup 3 Feb 24 15:17:34 Tower kernel: mdcmd (57): spinup 4 Feb 24 15:17:34 Tower kernel: mdcmd (58): spinup 5 Feb 24 15:32:35 Tower kernel: mdcmd (59): spindown 0 Feb 24 15:32:36 Tower kernel: mdcmd (60): spindown 1 Feb 24 15:32:36 Tower kernel: mdcmd (61): spindown 2 Feb 24 15:32:37 Tower kernel: mdcmd (62): spindown 3 Feb 24 15:32:37 Tower kernel: mdcmd (63): spindown 4 Feb 24 15:32:38 Tower kernel: mdcmd (64): spindown 5
  12. So now none of my disks will spin down. Got all the messages in the log (times seem spread out to me compared to spin down button, but that could be due to reboot and last access on each disk): Feb 24 15:11:23 Tower kernel: mdcmd (41): spindown 0 Feb 24 15:11:24 Tower kernel: mdcmd (42): spindown 5 Feb 24 15:12:37 Tower kernel: mdcmd (43): spindown 1 Feb 24 15:12:55 Tower kernel: mdcmd (44): spindown 2 Feb 24 15:13:04 Tower kernel: mdcmd (45): spindown 3 Feb 24 15:13:15 Tower kernel: mdcmd (46): spindown 4 But all remain active in the UI. I am not at home to confirm that they were indeed spinning. Spin down all button seems to reflect in UI: Feb 24 15:15:39 Tower kernel: mdcmd (47): spindown 0 Feb 24 15:15:39 Tower kernel: mdcmd (48): spindown 1 Feb 24 15:15:39 Tower kernel: mdcmd (49): spindown 2 Feb 24 15:15:40 Tower kernel: mdcmd (50): spindown 3 Feb 24 15:15:40 Tower kernel: mdcmd (51): spindown 4 Feb 24 15:15:41 Tower emhttp: shcmd (65): /usr/sbin/hdparm -y /dev/sdb &> /dev/null Feb 24 15:15:41 Tower kernel: mdcmd (52): spindown 5 I've spun them all up as a test. I'll try another reboot later to test as well.
  13. Update through plugins page went smooth. Thank you sir! Here is to hoping my drives spin down.
  14. I had the same thought. In addition, not know what fixed it if it actually is this time, could lead to another break in the future.
  15. It happens in my system with a WD40EZRX drive in the parity slot. Steps to recreate: [*]Spin up the problem drive by itself [*]Wait for spin down delay [*]"spindown 0" appears in the syslog, but drive does not spin down I watched power consumption and listened as "spindown 0" appeared in the syslog. I heard disk head movement but power consumption did not drop as it usually does with a successful spin down. Unfourtunately, for limetech, it hasn't been this easy to reproduce. They were able to in beta12, then moved to 13 and saw the issue go away. But based on what jonp said earlier, possible we had two different issues with one solved now (non-WD drives). I had all WD drives for beta12, but recently added a Seagate drive I wasn't using for anything else. The Seagate drive doesn't have content on it yet, but I plan to use it as an archive disk for TV Shows I don't re-watch often. Currently for me, data disk 1 (WDC_WD20EARX-00PASB0) and 2 (WDC_WD20EARS-00MVWB0) are the ones that aren't spinning down. Both WD green drives (all mine are green). I didn't have any luck in beta12 tracking this down, so not sure what to do next. I also have notifications disabled and UI refresh disabled.