Schwiing

Members
  • Content Count

    47
  • Joined

  • Last visited

Everything posted by Schwiing

  1. I am too. Thanks for the quick replies and let me know if you want me to test anything else out for troubleshooting.
  2. Looks correct to me: 0 0 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "resume" &> /dev/null 0 7 * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "pause" &> /dev/null 17 * * * * /usr/local/emhttp/plugins/parity.check.tuning/parity.check.tuning.php "monitor" &>/dev/null
  3. The check started on 4/1. The update was on 3-30. What am I missing?
  4. I'm confused. Wasn't the syntax error issue resolved with the 3-30 update? Or what syntax error are you referring to?
  5. This was the original check that started at midnight on April 1st (Today). The pause time was scheduled for 0700 and when I checked at 0715, the check wasn't paused, then I started to troubleshoot.
  6. On the latest v3-30 plugin and this morning's parity check did not pause. Furthermore, if I try to set a different time for the pause while the parity check is running, 95% of the time the changes don't stick when hitting "apply". (i.e. changing the pause and resume times). I can toggle the scheduled check to yes or no, but the times usually don't change. I also tried reinstalling the plugin but the same behavior was exhibited. I'm on unraid 6.9.1. EDIT: Changing increment frequency to custom and changing the pause/resume times with crontab format work, but I can't enable sending notifica
  7. Cool, no worries, and thanks for the explanation. As long as it pauses and resumes properly for scheduled runs on stable, I'm happy
  8. I'd be willing to try it if it were compatible with stable. Is there an incompatibility issue?
  9. Yep, same here. That has been my temporary workaround for now, despite not wanting that behavior long-term.
  10. At least in my instance, the parity history looks like it finished the parity check, but also has an aborted message (when it paused). Strange.
  11. I got the same notification. Strange.
  12. This time it worked. Strange. Attached the log + parity tuning files. Parity.zip
  13. I can only get my parity check to pause if i set "Use Increments for Unscheduled Parity Check:" to yes. Despite it being a scheduled event, I'm not sure why it won't pause unless setting this option to yes. I'm on Stable unraid with the latest plugin version.
  14. Right, which is very weird. Is there anywhere in my logs I can check if the memory is incompatible or anything else? I have 64GB of ram with no VMs and a handful of dockers that use ~11GB of RAM total. I can't figure out what the issue is.
  15. This is from my syslog last week. I forgot I accidentally turned it off this week, hence the lack of logs for the latest crash: https://paste.ubuntu.com/p/tfNzSNDRGb/
  16. It did not. I'm not sure if its memory related or what. I can't tell from the logs
  17. About once a week or so, my unraid server crashes and I'm not sure why. About 4 weeks ago, i swapped out my hardware from a dual xeon system to an EPYC 7302P with 64GB of DDR4-2400 ECC RAM. Everything seems to run fine until the server crashes in the middle of the night and I don't know why. I attached my diagnostics file. Any help running this down would be MUCH appreciated. Thanks. adrastea-diagnostics-20200623-0856.zip
  18. Seems to be happening any time I write to the array.
  19. I have a JBOD connected to my compute (unraid) box with two SAS3 (SFF-8644) cables. Both look nominal and are showing OK lights. (The JBOD is a QV JB 4242)
  20. Thanks in advance for the help. Getting a lot of this in my syslog. Not sure what it means (seems related to my SAS controller but otherwise, no idea): May 26 05:05:13 ADRASTEA kernel: sd 3:0:4:0: Power-on or device reset occurred May 26 05:06:29 ADRASTEA kernel: mpt3sas_cm0: log_info(0x31110e03): originator(PL), code(0x11), sub_code(0x0e03) Anyone know what's going on? Diagnostics attached also. adrastea-diagnostics-20200526-0853.zip
  21. Welp, I figured it out (likely no one else with this issue but just in case).... So, my unraid box is connected via a 10G NIC. Way back when, I was told to set my NIC's MTU to 9000 with jumbo frames on in my switch upstream to utilize full speed. Turns out, this is what messed up my (well my instance of) unraid-nvidia plugin. With MTU set back to 1500 on the NIC, it popped up the builds within seconds and now I'm slowly downloading it as CHBMB intended it to be What a headache...all self inflicted.
  22. Thanks @CHBMB for the script. It's been downloading for hours...no idea why my network hates that destination so much
  23. Is there a way to download the latest build manually? I keep getting upstream timeout errors.
  24. Did a search and couldn't find this exact issue for weeks on this topic, but if it's already been mentioned and I missed it, I apologize. When trying to load the latest available builds, I get this in the logs (and the builds never load): nginx: 2020/02/09 11:10:13 [error] 7421#7421: *52 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 192.168.1.201, server: , request: "POST /plugins/Unraid-Nvidia/include/exec.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm.sock", host: "192.168.1.102:81", referrer: "http://19
  25. How do I begin? There are so many things to like about Unraid. I’ve been storing data (on more than just the conventional desktop platform) for over 15 years. For years hardware RAID was the king of redundancy. RAID 1, 5, 1+0…these were my bread and butter. And back then, having so many gigabytes at my disposal came with the peace of mind that my data was safe (of course, by means of backup both locally and remotely) with a disk failure or two. But those days were difficult as hard drives kept increasing in size and changed brand…heck even PATA was gone in favor of SATA. Those were different t