jcreynoldsii

Community Developer
  • Content Count

    97
  • Joined

  • Last visited

Community Reputation

1 Neutral

About jcreynoldsii

  • Rank
    Newbie
  • Birthday 03/16/1989

Converted

  • Gender
    Male
  • Location
    IL, USA

Recent Profile Visitors

874 profile views
  1. For the last 3 nights I have experienced hard crashes. From the syslog there isn't any valuable information that I can gather just prior to crashing. Any insight/help is much appreciated. Attached are the diagnostics and syslog homeserver-diagnostics-20200927-0853.zip syslog-192.168.1.2.log
  2. Not that I could tell, issue has resolved itself for now. Thanks.
  3. unraid os: 6.8.3 Apps: 2020.07.13 My community apps section is no longer loading, get this message instead: Something really wrong went on during get_content Post the ENTIRE contents of this message in the Community Applications Support Thread No data was returned. It is probable that another browser session has rebooted your server. Reloading this browser tab will probably fix this error What can I do to determine cause? Jay
  4. So been stabled for ~10 days now with only running a few of the most critical dockers and only running the mover on sundays rather than each day. Next test was enable a few more dockers and take the mover back to daily. I'll run like this for a 4-5 days to make sure all is stable. From there proceed to enabling more dockers.
  5. Last check completed on Tue 26 May 2020 03:33:54 PM CDT (today), finding 0 errors. That's good news.
  6. Running a non-correcting parity check as we speak. I'll check cabling after parity check completes tomorrow.
  7. No crashes over night, I did however changed the mover schedule so that it would not run. I did this simply because I wanted the parity check to finish as it had already found and corrected errors. Presumably because it hard crashed yesterday during the parity check from the previous hard crash. Date Duration Speed Status Errors 2020-05-25, 08:25:18 21 hr, 39 min, 34 sec 102.6 MB/s OK 129 I ran only the bare minimum of dockers last night, PiHole, Unifi-Controller and Plex. I will slowly introduce dockers over the next few days to see if these crashes are docker related. In the
  8. Used User Scripts and made the following script: #!/bin/bash mkdir /tmp/PlexRam mount -t tmpfs -o size=4g tmpfs /tmp/PlexRam Updated the docker command and the transcode setting in Plex
  9. No I don't use Plex DVR and I don't have anything mapped for trans-coding. Should I make a directory on a share drive for it? Or should I transcode to RAM? I'd have to give it a shot on shutting down docker, I planned on doing that tonight before turning in for the night. I don't want to run with it off during day as I use PiHole for DNS and without a secondary PiHole running it pretty much will shutdown the internet in the house. The reason I initially suspected Plex to be my culprit is because I would experience a lot of hard crashes while casting Plex to t
  10. I have a total of 22 containers installed, and out of those 22 I run 18 full time. Attached is a list of those containers along with their run commands. unRaid Dockers - Sheet1.pdf
  11. My docker is image size is set to 50GB, I am using about 23GB of that. At one point in the past I ran out of docker image size so I increased it. All of my dockers reside on the cache/appdata directory and I believe that all of my mapped directories reside on shares. Plex docker configuration: All of my dockers reside on the cache/appdata directory. I am wondering if the mover app isn't what got me, considering the last two days I woke up to a hard crashed system.
  12. Yet another one this morning. Last message before rebooting it this morning was: May 24 02:30:07 HomeServer crond[1722]: exit status 1 from user root /usr/local/sbin/mover &> /dev/null Edit: Mover is setup to go off at 2:30 am, however Mover logging was not enabled, I have since enabled it. I shutdown all non-essential dockers this morning so this system can finish a parity check, it has crashed two days in a row while performing the parity check due to the unclean hard reboots for the day prior. syslog-192.168.1.2.log homeserver-diagnostics-20200524-1048.zip
  13. Woke up to another hard crash this morning. Had to do a unclean reboot at 8:38 AM. syslog-192.168.1.2.log homeserver-diagnostics-20200523-0840.zip
  14. This look better? #!/bin/bash # Start the Management Utility /usr/local/sbin/emhttp & # resize log partition mount -o remount,size=384m /var/log How can I troubleshoot the crashes? The log has nothing tangible in there. I would like to be able to gracefully shutdown unraid, however the console keyboard doesnt work, web gui and web interfaces gone, the quick press of the power button doesn't work and neither does pulling UPS from mains power. It seems like unraid gets hung 100%.
  15. Checked my log and there are several peculiar entries from dockers: May 21 19:36:21 HomeServer kernel: docker0: port 9(vethfafdac9) entered blocking state May 21 19:36:21 HomeServer kernel: docker0: port 9(vethfafdac9) entered forwarding state May 21 19:36:21 HomeServer kernel: docker0: port 9(vethfafdac9) entered disabled state May 21 19:36:21 HomeServer kernel: eth0: renamed from veth7d7cd71 May 21 19:36:21 HomeServer kernel: IPv6: ADDRCONF(NETDEV_CHANGE): vethfafdac9: link becomes ready May 21 19:36:21 HomeServer kernel: docker0: port 9(vethfafdac9) entered blocking state May 21 19:36:2