August 3, 20196 yr Hi everybody, Firstly, I've been running unRAID coming up on 10 years. It has always performed flawlessly for me. But my box has been acting up lately. After upgrading to 6.7.2 (might be unrelated, but it seems to coincide), I've seen: Losing connection with my APC UPS, which was always fine before. The date is set incorrectly from the NTP server (about 3 hours and 15 minutes late, if that makes any sense...) As of august 1st, I am getting a slew of read errors across all drives. It seems strange to me that all of a sudden, _all_ the drives would start having read errors. I attempted to rebuild parity (the parity drive was one of the ones with read errors), but that failed. I'm currently running a read check and waiting anxiously for the result. I feel it is unlikely that almost all my drives would start having read errors all of a sudden. My next steps: SMART extended test on a sample of the drives (starting with the parity drive). Physical inspection of the machine. Blow out dust and reseat all cables. Pull all drives and restart with a fresh unRAID 6.7.2 install and a couple of 2TB drives I have sitting on a shelf. If this fails to bring back a stable install, I'm at a loss. Order a new motherboard and CPU, maybe? Any suggestions? I'm kind of freaking out... Diagnostics attached for reference. Thanks in advance for any advice! Paul shadow-diagnostics-20190802-1824.zip
August 3, 20196 yr Community Expert 11 minutes ago, paulprovost said: After upgrading to 6.7.2 What version did you upgrade from?
August 3, 20196 yr 03:00.0 SATA controller [0106]: Marvell Technology Group Ltd. Device [1b4b:9215] (rev 11) Subsystem: Marvell Technology Group Ltd. Device [1b4b:9215] Kernel driver in use: ahci Kernel modules: ahci Marvel based controllers haven't been recommended to use for a few years now as Marvel is one of those companies that doesn't particularly care about driver issues, and as time goes by those issues are getting worse and worse. You should change it out for a LSI based controller
August 3, 20196 yr Community Expert Are the problem disks plugged in to Marvell? Do you have enough other ports to let you get all disks off Marvell? Maybe some of these problems are unrelated but coincidentally happening now. You might try plugging the UPS into a different port. Or maybe the UPS itself is the source of the problem. As for your ntp problems, something in the syslog doesn't look right about that. Jul 30 21:02:50 shadow emhttpd: req (3): timeZone=America%2FNew_York&USE_NTP=yes&NTP_SERVER1=0.pool.ntp.o+rg&NTP_SERVER2=&NTP_SERVER3=&NTP_SERVER4=&setDateTime=Apply&csrf_token=**************** Jul 30 21:02:50 shadow emhttpd: shcmd (7825): ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime-copied-from Jul 30 21:02:50 shadow emhttpd: shcmd (7826): cp /etc/localtime-copied-from /etc/localtime Jul 30 21:02:50 shadow emhttpd: shcmd (7827): /usr/local/emhttp/webGui/scripts/update_access Jul 30 21:02:50 shadow sshd[6207]: Received signal 15; terminating. Jul 30 21:02:51 shadow sshd[3017]: Server listening on 0.0.0.0 port 22. Jul 30 21:02:51 shadow sshd[3017]: Server listening on :: port 22. Jul 30 21:02:52 shadow emhttpd: shcmd (7828): /etc/rc.d/rc.ntpd restart Jul 30 21:02:52 shadow ntpd[1672]: ntpd exiting on signal 1 (Hangup) Jul 30 21:02:52 shadow ntpd[1672]: 127.127.1.0 local addr 127.0.0.1 -> <null> Jul 30 21:02:52 shadow ntpd[1672]: 192.99.2.172 local addr 192.168.1.251 -> <null> Jul 30 21:02:52 shadow root: Stopping NTP daemon... Jul 30 21:02:53 shadow ntpd[3036]: ntpd [email protected] Fri Mar 8 17:57:36 UTC 2019 (1): Starting Jul 30 21:02:53 shadow ntpd[3036]: Command line: /usr/sbin/ntpd -g -u ntp:ntp Jul 30 21:02:53 shadow root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp Jul 30 21:02:53 shadow ntpd[3038]: proto: precision = 0.419 usec (-21) Jul 30 21:02:53 shadow ntpd[3038]: line 86 column 20 syntax error, unexpected T_String, expecting T_EOC Jul 30 21:02:53 shadow ntpd[3038]: syntax error in /etc/ntp.conf line 86, column 20 Notice the part in the first line above NTP_SERVER1=0.pool.ntp.o+rg The '+' makes me think some invalid character is in there, since normally URL encodes a space as '+'. And the last lines above mention a syntax error. I don't know if my guesses about this are correct or not, but you might try entering the timeservers again in Settings - Date and Time and saving them to see if that makes any difference.
August 4, 20196 yr Author On 8/3/2019 at 3:36 PM, trurl said: Are the problem disks plugged in to Marvell? Do you have enough other ports to let you get all disks off Marvell? Maybe some of these problems are unrelated but coincidentally happening now. You might try plugging the UPS into a different port. Or maybe the UPS itself is the source of the problem. As for your ntp problems, something in the syslog doesn't look right about that. Jul 30 21:02:50 shadow emhttpd: req (3): timeZone=America%2FNew_York&USE_NTP=yes&NTP_SERVER1=0.pool.ntp.o+rg&NTP_SERVER2=&NTP_SERVER3=&NTP_SERVER4=&setDateTime=Apply&csrf_token=**************** Jul 30 21:02:50 shadow emhttpd: shcmd (7825): ln -sf /usr/share/zoneinfo/America/New_York /etc/localtime-copied-from Jul 30 21:02:50 shadow emhttpd: shcmd (7826): cp /etc/localtime-copied-from /etc/localtime Jul 30 21:02:50 shadow emhttpd: shcmd (7827): /usr/local/emhttp/webGui/scripts/update_access Jul 30 21:02:50 shadow sshd[6207]: Received signal 15; terminating. Jul 30 21:02:51 shadow sshd[3017]: Server listening on 0.0.0.0 port 22. Jul 30 21:02:51 shadow sshd[3017]: Server listening on :: port 22. Jul 30 21:02:52 shadow emhttpd: shcmd (7828): /etc/rc.d/rc.ntpd restart Jul 30 21:02:52 shadow ntpd[1672]: ntpd exiting on signal 1 (Hangup) Jul 30 21:02:52 shadow ntpd[1672]: 127.127.1.0 local addr 127.0.0.1 -> <null> Jul 30 21:02:52 shadow ntpd[1672]: 192.99.2.172 local addr 192.168.1.251 -> <null> Jul 30 21:02:52 shadow root: Stopping NTP daemon... Jul 30 21:02:53 shadow ntpd[3036]: ntpd [email protected] Fri Mar 8 17:57:36 UTC 2019 (1): Starting Jul 30 21:02:53 shadow ntpd[3036]: Command line: /usr/sbin/ntpd -g -u ntp:ntp Jul 30 21:02:53 shadow root: Starting NTP daemon: /usr/sbin/ntpd -g -u ntp:ntp Jul 30 21:02:53 shadow ntpd[3038]: proto: precision = 0.419 usec (-21) Jul 30 21:02:53 shadow ntpd[3038]: line 86 column 20 syntax error, unexpected T_String, expecting T_EOC Jul 30 21:02:53 shadow ntpd[3038]: syntax error in /etc/ntp.conf line 86, column 20 Notice the part in the first line above NTP_SERVER1=0.pool.ntp.o+rg The '+' makes me think some invalid character is in there, since normally URL encodes a space as '+'. And the last lines above mention a syntax error. I don't know if my guesses about this are correct or not, but you might try entering the timeservers again in Settings - Date and Time and saving them to see if that makes any difference. Thanks trurl, No, not all the disks were plugged into Marvell. But I'll look into replacing that card with an LSI-based one. Any cheap suggestions? It seems that the read check on the parity drive went well. I removed the parity drive, stopped, started and re-enabled it. It is now rebuilding and is up to 85% with no problems. Last night's status report showed all disks Ok, except for the parity, which is normal because it is rebuilding. For the UPS, thanks for the suggestion. I'll try oher ports. Thanks for locating the NTP logs for me. I'll look at the line causing a syntax error. I'll chalk the whole thing up to a glitch, but it had me worried there for a while. I'll work on finding a cheapish LSI-based SATA card to replace the Marvell one. Thanks!
Archived
This topic is now archived and is closed to further replies.