March 20, 201610 yr I'm also experiencing this, being unable to stop the docker process and first SAB hangs, then the whole unRAID UI hangs. It seems to happen during par2, but I don't believe my CPU is at fault as I've never had this problem before. I have tried scrubbing my cache drive and had 0 errors, but the SMART reports for it do indeed contain some old age and prefail attributes. Is it possible that my cache drive is causing this and needs replaced? Or is there a way to find a definitive answer before spending the $$ on one to find out? I can't imagine everyone with this issue has a cache drive on the way out but I suppose it's possible? I'm also using needo's docker still. Should I switch to another? I see tons of people complaining about SabNzBD doing this, and have yet to see anyone complain about NzbGet (which is far better anyways)
March 20, 201610 yr Get is definitely much lite-er. I have no problem switching. Just would like an response as to the actual issue is all if anyone figures one out.
March 21, 201610 yr I have this isue on nzbGet too :-( and i have change entire hardware to Dell Power Edge 110 II Intel® Xeon® CPU E31220 @ 3.10GHz and 8GB ECC because old one not support VM. Only Disks are my, but this anoying isue still exist... I try intall nzbGet outside docker...
March 21, 201610 yr Since they both utilize the same underlying programs, unrar and par2, I would have to think something is allowing the par2 process to completely eat all of the system resources. I didn't think that could happen with docker? I've tried to watch top, and at no point does my CPU usage get what I would consider exceedingly high. It stays ~ 50-60%. Because of this I'd lean more towards what danioj says, that this is some type of bug that causes the network interface to drop connection. This should not lock the system unless some other issue was presenting right?
March 21, 201610 yr On nzbGet installed as Plugin probelm the same... After 18GB downloading from 33GB all GUI from Tower/Sonarr/Couch Potato/nzbGet and Windows 7 on VM hangs... That lokking something like connection stop responding i see that download on nzbGet slow down form 10MB/s to down with constatnt speed. After that i open Tower GUI and on changing second site of GUI all stops responding... Tenlnet nad SMB working.
March 21, 201610 yr On nzbGet installed as Plugin probelm the same... After 18GB downloading from 33GB all GUI from Tower/Sonarr/Couch Potato/nzbGet and Windows 7 on VM hangs... That lokking something like connection stop responding i see that download on nzbGet slow down form 10MB/s to down with constatnt speed. After that i open Tower GUI and on changing second site of GUI all stops responding... Tenlnet nad SMB working. This is WITHOUT a doubt an issue. I just can't find out where! As I mention in earlier posts it is SOMEWHERE between Docker>unRAID>Network Config>Local Hardware BUT who knows where. Unfortunately unRAID diagnostics are useless in diagnosing this as the issue / error seems to be silent. As a means of isolation I have made the ultimate switch today and setup GET and SAB in a VM. I am going to hammer them with downloading a nix iso over and over again @ 2.5MB/s constant for a week. Let's see if it crashes the network of the box. I will report back in 1 week / IF the issue persists.
March 21, 201610 yr On nzbGet installed as Plugin probelm the same... After 18GB downloading from 33GB all GUI from Tower/Sonarr/Couch Potato/nzbGet and Windows 7 on VM hangs... That lokking something like connection stop responding i see that download on nzbGet slow down form 10MB/s to down with constatnt speed. After that i open Tower GUI and on changing second site of GUI all stops responding... Tenlnet nad SMB working. Step 1, ditch plugin. Step 2, use nzbget docker. Step 3, report back your findings.
March 21, 201610 yr On nzbGet installed as Plugin probelm the same... After 18GB downloading from 33GB all GUI from Tower/Sonarr/Couch Potato/nzbGet and Windows 7 on VM hangs... That lokking something like connection stop responding i see that download on nzbGet slow down form 10MB/s to down with constatnt speed. After that i open Tower GUI and on changing second site of GUI all stops responding... Tenlnet nad SMB working. Step 1, ditch plugin. Step 2, use nzbget docker. Step 3, report back your findings. This seems to be spanning both applications. I have tested: - SAB in Plugin AND Docker - GET in Docker I am now testing SAB and GET in VM. I still think this is an unRAID / Network / Traffic Volume issue, but once again this is Anecdotal as (as I have noted due to lack of errors / good information in logs) gathering evidence on this issue is very hard.
March 22, 201610 yr I have try today stops all dockers and vm and use only nzbGet in plugin... I have update to unRaid 6.2.0. Effect the same but i see that Hard Drve light on my machine when that hapens light constantly. That was on old hardware and on new. But Today I tryied login on nzbGet nad succes GUI was really lagy but i have chance to pause download and everything going back to normal without restart . I have download Tower diagnostic but im reely have no clue on unix linux systems. I can send via PM or e-mail to analize.
March 22, 201610 yr I have try today stops all dockers and vm and use only nzbGet in plugin... Effect the same but i see that Hard Drve light on my machine when that hapens light constantly. That was on old hardware and on new. But Today I tryied login on nzbGet nad succes GUI was really lagy but i have chance to pause download and everything going back to normal without restart . I have download Tower diagnostic but im reely have no clue on unix linux systems. I can send via PM or e-mail to analize. just post it publicly. It's been processed to remove share names, email addresses, etc
March 22, 201610 yr Ok there is Looks like your cache drive is literally having a heart attack Mar 22 19:54:52 Tower kernel: ata5.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen Mar 22 19:54:52 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED Mar 22 19:54:52 Tower kernel: ata5.00: cmd 61/a8:00:c0:65:02/07:00:08:00:00/40 tag 0 ncq 1003520 out Mar 22 19:54:52 Tower kernel: res 40/00:00:01:01:80/00:00:00:00:00/00 Emask 0x4 (timeout) All of these errors are definitely going to massively slow things down. I would look at cabling issues - slightly loose sata cable and/or power cable. Crappy power splitter. Crappy sata cable, etc
March 22, 201610 yr Or damaged disk ? Only this is from my old one machine... Cables are diffrent and the isue is the same. But problem exist on first use of unRaid. New is Cache and Parity and thre old one are woking further on Windows 7 machine. Ok I take look on Ata 5 and change disks with place.
March 22, 201610 yr On nzbGet installed as Plugin probelm the same... After 18GB downloading from 33GB all GUI from Tower/Sonarr/Couch Potato/nzbGet and Windows 7 on VM hangs... That lokking something like connection stop responding i see that download on nzbGet slow down form 10MB/s to down with constatnt speed. After that i open Tower GUI and on changing second site of GUI all stops responding... Tenlnet nad SMB working. Step 1, ditch plugin. Step 2, use nzbget docker. Step 3, report back your findings. This seems to be spanning both applications. I have tested: - SAB in Plugin AND Docker - GET in Docker I am now testing SAB and GET in VM. I still think this is an unRAID / Network / Traffic Volume issue, but once again this is Anecdotal as (as I have noted due to lack of errors / good information in logs) gathering evidence on this issue is very hard. Reporting back early on this issue as a result of this comment by BRiT: On nzbGet installed as Plugin probelm the same... After 18GB downloading from 33GB all GUI from Tower/Sonarr/Couch Potato/nzbGet and Windows 7 on VM hangs... That lokking something like connection stop responding i see that download on nzbGet slow down form 10MB/s to down with constatnt speed. After that i open Tower GUI and on changing second site of GUI all stops responding... Tenlnet nad SMB working. Step 1, ditch plugin. Step 2, use nzbget docker. Step 3, report back your findings. I do respect BRiT's comments so I wanted to "throughly" test his theory. I installed the plugin on my Server last night. Disabled the VM for now (as noted in what I am doing above) - set it running downloading nix iso's and it seemed to work VERY well. I woke up this morning and everything was still working fine. That was 12 hours. Over that time there was repairs, unpacks etc. Then at 8:30. Lockup. The WEB GUI, Docker GUI's, Telnet & shh were either unavailable / timing out OR slow! Reset of the network interface (via IPMI) and BANG everything is back up and running again. Absolutely NOTHING related to this was recorded in unRAID Log's in this time. However, I did notice something in the GET logs (which I never noticed from SAB). In-between the hours of 10pm and 7am there was a plethora of: Could not read / write from TLS-Socket AND OR TLS handshake failed Since my restart of the network this morning (to deal with the lockup) I have had none. I found myself thinking "I KNEW this had something to do with SSL" BUT I still don't know what. There is some discussion on the web about this. Suggestions have ranged from: - ISP throttling - Incorrect Cypher - Server issues - Unknown I just don't know IF these issues are causing this or if it is something else. This one is a HARD one to debug.
March 23, 201610 yr OK. I think I have had a breakthrough with this. I got so bloody annoyed with not being able to work this out. GUI crashes (as others have noted) can almost be clockwork. Something IS happening. Anyway at the times I have noticed "Crashes" I started looking at the process list. I noticed something this morning that I have almost confirmed tonight. Thankfully (IF it is this) it has nothing DIRECTLY to do with SAB or GET but indirectly with the amount of external Bandwidth being used at the time. Hence why restarting the network, dockers seems to work! Anyway, here goes. I have noticed that on or around the "Crash" or time of unresponsiveness something like the following appears in the process list: root 8089 0.0 0.0 9328 2232 ? S 18:20 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 8091 0.0 0.0 109556 16392 ? S 18:20 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/monitor root 8170 0.0 0.0 9328 2196 ? S 18:20 0:00 sh -c /usr/sbin/update-smart-drivedb 1>/dev/null 2>&1 root 8171 0.0 0.0 9356 2372 ? S 18:20 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 8721 0.0 0.0 9356 1752 ? S 18:20 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 8722 0.0 0.0 32924 4948 ? S 18:20 0:00 curl -s -f -o /usr/share/smartmontools/drivedb.h.new http://sourceforge.net/p/smartmontools/code/HEAD/tree/trunk/smartmontools/drivedb.h?format=raw root 8799 0.0 0.0 4364 648 ? S 18:21 0:00 sleep 10 root 8801 0.0 0.0 4364 684 ? S 18:21 0:00 sleep 1 root 8089 0.0 0.0 9328 2232 ? S 18:20 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 8091 0.0 0.0 109556 16392 ? S 18:20 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/monitor root 8170 0.0 0.0 9328 2196 ? S 18:20 0:00 sh -c /usr/sbin/update-smart-drivedb 1>/dev/null 2>&1 root 8171 0.0 0.0 9356 2368 ? S 18:20 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 8176 0.0 0.0 9356 1752 ? S 18:20 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 8177 0.0 0.0 32924 5000 ? S 18:20 0:00 curl -s -f -o /usr/share/smartmontools/drivedb.h.new http://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw root 12684 0.0 0.0 9328 2168 ? S 18:26 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 12686 0.0 0.0 109556 15836 ? S 18:26 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/monitor root 12687 0.0 0.0 9332 2236 ? S 18:26 0:00 sh -c wget -qO /dev/null 127.0.0.1:$(lsof -i -P -sTCP:LISTEN|grep -Pom1 '^emhttp.*:\K\d+')/update.htm?cmdStatus=apply root 12688 0.0 0.0 9332 2008 ? S 18:26 0:00 sh -c wget -qO /dev/null 127.0.0.1:$(lsof -i -P -sTCP:LISTEN|grep -Pom1 '^emhttp.*:\K\d+')/update.htm?cmdStatus=apply root 12689 0.3 0.0 17232 2236 ? S 18:26 0:00 lsof -i -P -sTCP:LISTEN root 12690 0.0 0.0 4676 760 ? S 18:26 0:00 grep -Pom1 ^emhttp.*:\K\d+ root 15869 0.0 0.0 9328 2196 ? S 18:28 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 15870 0.0 0.0 109556 16256 ? S 18:28 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/monitor root 15876 0.0 0.0 9328 2196 ? S 18:28 0:00 sh -c /usr/sbin/update-smart-drivedb 1>/dev/null 2>&1 root 15877 0.0 0.0 9356 2360 ? S 18:28 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 15882 0.0 0.0 9356 1692 ? S 18:28 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 15883 0.0 0.0 32924 5048 ? S 18:28 0:00 curl -s -f -o /usr/share/smartmontools/drivedb.h.new http://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw root 15946 0.0 0.0 9500 2172 pts/2 R+ 18:28 0:00 ps aux --sort=start_time root 16860 0.0 0.0 9328 2264 ? S 18:29 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 16861 0.0 0.0 109556 16048 ? S 18:29 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/monitor root 16874 0.0 0.0 9332 2344 ? S 18:29 0:00 sh -c wget -qO /dev/null 127.0.0.1:$(lsof -i -P -sTCP:LISTEN|grep -Pom1 '^emhttp.*:\K\d+')/update.htm?cmdStatus=apply root 16875 0.0 0.0 9332 2028 ? S 18:29 0:00 sh -c wget -qO /dev/null 127.0.0.1:$(lsof -i -P -sTCP:LISTEN|grep -Pom1 '^emhttp.*:\K\d+')/update.htm?cmdStatus=apply root 16876 0.1 0.0 17232 2380 ? S 18:29 0:00 lsof -i -P -sTCP:LISTEN root 16877 0.0 0.0 4676 772 ? S 18:29 0:00 grep -Pom1 ^emhttp.*:\K\d+ root 16889 0.0 0.0 4364 744 ? S 18:29 0:00 sleep 6 root 16907 0.0 0.0 4364 684 ? S 18:29 0:00 sleep 1 root 16908 0.0 0.0 9500 2240 pts/2 R+ 18:29 0:00 ps aux --sort=start_time I don't know what is going on here BUT it "appears" to me that Dynamix / unRAID is checking something. Updates perhaps - I can't tell - BUT from what I can see at least "some" of them are EXTERNAL requests. Here is a riddle. Given how emhhtp works IF I am eating ALL my bandwidth and as such these requests are not being able to be made / timing out could this hang the GUI / Network of unRAID? This would answer the question as to why people (including me) think it is SAB / GET because those using those Dockers are perhaps using ALL their available EXTERNAL bandwidth regularly!? It might also account for the observations that the Crashes / Lock ups appear to be like "clockwork" and somewhat predictable? Someone with a bit more knowledge needs to chime in here BUT I think I have locked onto something .....
March 23, 201610 yr Those commands are looping now ..... root 28345 0.0 0.0 9328 2264 ? S 18:41 0:00 /bin/sh -c /usr/local/emhttp/plugins/dynamix/scripts/monitor &> /dev/null root 28347 0.0 0.0 109556 16480 ? S 18:41 0:00 /usr/bin/php -q /usr/local/emhttp/plugins/dynamix/scripts/monitor root 28352 0.0 0.0 9328 2188 ? S 18:41 0:00 sh -c /usr/sbin/update-smart-drivedb 1>/dev/null 2>&1 root 28353 0.0 0.0 9356 2388 ? S 18:41 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 28358 0.0 0.0 9356 1688 ? S 18:41 0:00 /bin/sh /usr/sbin/update-smart-drivedb root 28359 0.0 0.0 32924 4992 ? S 18:41 0:00 curl -s -f -o /usr/share/smartmontools/drivedb.h.new http://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw root 28375 0.0 0.0 0 0 ? S< 18:41 0:00 [kworker/u17:4] root 28376 0.0 0.0 0 0 ? S< 18:41 0:00 [kworker/u17:5] root 28386 0.0 0.0 0 0 ? S 18:41 0:00 [kworker/1:0] root 28552 0.0 0.0 4364 636 ? S 18:41 0:00 sleep 10 root 28566 0.0 0.0 4364 720 ? S 18:41 0:00 sleep 1 root 28567 0.0 0.0 9652 2436 pts/2 R+ 18:41 0:00 ps aux --sort=start_time I am noticing also that in between those loops there are these commands: root 30520 0.0 0.0 4364 756 ? S 18:44 0:00 sleep 5 root 30529 0.0 0.0 4364 636 ? S 18:44 0:00 sleep 1 root 30531 0.0 0.0 9652 2360 pts/2 R+ 18:44 0:00 ps aux --sort=start_time So I have taken a DIFFERENT approach given what I appear to have found above. Instead of restarting the GET / SAB Docker I have stopped it (In essence freeing up ALL my EXTERNAL Bandwidth). Initially I have seen NO change. GUI is non responsive / timing our OR laggy and is only rendering PART of the page. Similar behaviour to normal. More than anything it is this command I am seeing .... curl -s -f -o /usr/share/smartmontools/drivedb.h.new http://sourceforge.net/p/smartmontools/code/HEAD/tree/branches/RELEASE_6_2_DRIVEDB/smartmontools/drivedb.h?format=raw I have NO idea how to KILL this loop BUT the freeing up of Bandwidth hasn't had the effect I thought it would have. Things are just looping over and over again. AND now the telnet season has died. NO response from the GUI at ALL. Time to go to the IPMI interface and I think it is time to restart the network interface with a ... /etc/rc.d/rc.inet1 restart And there we go. EVERYTHING is back up and working! The loop "appears" to have stopped. There is no more of those "wait" commands either, so whatever it was that was running has stopped for now. What do others think?
March 23, 201610 yr Following restart of network interface. Sleep commands still appear BUT no more of the "other" ones! GUI (and Docker GUI's) as always now working as normal. If that is NOT something to do with the issue I will eat a hat! As usual, pointless posting a diagnostics file. NOTHING in the logs at all!!
March 23, 201610 yr You are seeing the monitor script which runs every minute and does several updates. With the latest smartmontools version, something got broken either in their program or on their website, this prevents the monitor script to obtain the latest smart attribute file (download fails). The normal procedure is to download the file and re-check after one week for updates, but now it is trying every minute due to the always failing download. You can stop the download attempts by editing the /usr/local/emhttp/webGui/scripts/monitor script and comment out the following line 201: // if (!file_exists($smartDB) || (time()-filemtime($smartDB)>=$interval)) exec('/usr/sbin/update-smart-drivedb 1>/dev/null 2>&1'); See if that makes any change in your situation (these downloads are very low bandwidth), and I hope your hat is tasteful
March 23, 201610 yr You are seeing the monitor script which runs every minute and does several updates. With the latest smartmontools version, something got broken either in their program or on their website, this prevents the monitor script to obtain the latest smart attribute file (download fails). The normal procedure is to download the file and re-check after one week for updates, but now it is trying every minute due to the always failing download. You can stop the download attempts by editing the /usr/local/emhttp/webGui/scripts/monitor script and comment out the following line 201: // if (!file_exists($smartDB) || (time()-filemtime($smartDB)>=$interval)) exec('/usr/sbin/update-smart-drivedb 1>/dev/null 2>&1'); See if that makes any change in your situation (these downloads are very low bandwidth), and I hope your hat is tasteful If not Ill add sauce! Thanks for the tip. I have done as you suggested. Let's see if we get unresponsiveness in the next 12 hours! It has been clockwork for ages. Will report back.
March 23, 201610 yr You are seeing the monitor script which runs every minute and does several updates. With the latest smartmontools version, something got broken either in their program or on their website, this prevents the monitor script to obtain the latest smart attribute file (download fails). The normal procedure is to download the file and re-check after one week for updates, but now it is trying every minute due to the always failing download. You can stop the download attempts by editing the /usr/local/emhttp/webGui/scripts/monitor script and comment out the following line 201: // if (!file_exists($smartDB) || (time()-filemtime($smartDB)>=$interval)) exec('/usr/sbin/update-smart-drivedb 1>/dev/null 2>&1'); See if that makes any change in your situation (these downloads are very low bandwidth), and I hope your hat is tasteful If not Ill add sauce! Thanks for the tip. I have done as you suggested. Let's see if we get unresponsiveness in the next 12 hours! It has been clockwork for ages. Will report back. First Follow up is VERY positive. Since I uncommented that line as suggested by bonienl I have not had ANY lockup. Daily morning Crash has NOT occured. I don't have any of my mitigating daily cron jobs running resetting Dockers or Network interfaces. NZBGet Docker is running at full pelt. Switching over to SAB now to test that again. *fingers crossed*
March 25, 201610 yr You are seeing the monitor script which runs every minute and does several updates. With the latest smartmontools version, something got broken either in their program or on their website, this prevents the monitor script to obtain the latest smart attribute file (download fails). The normal procedure is to download the file and re-check after one week for updates, but now it is trying every minute due to the always failing download. You can stop the download attempts by editing the /usr/local/emhttp/webGui/scripts/monitor script and comment out the following line 201: // if (!file_exists($smartDB) || (time()-filemtime($smartDB)>=$interval)) exec('/usr/sbin/update-smart-drivedb 1>/dev/null 2>&1'); See if that makes any change in your situation (these downloads are very low bandwidth), and I hope your hat is tasteful 40 hours since making this simple change and I have not had a single WEB GUI crash at all.
March 25, 201610 yr See this bug report related to update-smart-drivedb: https://lime-technology.com/forum/index.php?topic=47386.0 If the fix listed there solves your problem, it should be easy for LT to implement without disabling the update entirely.
March 26, 201610 yr Ok there is Looks like your cache drive is literally having a heart attack Mar 22 19:54:52 Tower kernel: ata5.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x6 frozen Mar 22 19:54:52 Tower kernel: ata5.00: failed command: WRITE FPDMA QUEUED Mar 22 19:54:52 Tower kernel: ata5.00: cmd 61/a8:00:c0:65:02/07:00:08:00:00/40 tag 0 ncq 1003520 out Mar 22 19:54:52 Tower kernel: res 40/00:00:01:01:80/00:00:00:00:00/00 Emask 0x4 (timeout) All of these errors are definitely going to massively slow things down. I would look at cabling issues - slightly loose sata cable and/or power cable. Crappy power splitter. Crappy sata cable, etc For me problem is solved... i have replace Disk from ATA5 ( Cache ) to other SSD and no errors on ATA5 and no freezing of all GUI. Thanks for the sugestion. That sems unRaid dont like Plextor M6S ;-) I have testet One file 80GB and 30GB and all ok.
March 27, 201610 yr You are seeing the monitor script which runs every minute and does several updates. With the latest smartmontools version, something got broken either in their program or on their website, this prevents the monitor script to obtain the latest smart attribute file (download fails). The normal procedure is to download the file and re-check after one week for updates, but now it is trying every minute due to the always failing download. You can stop the download attempts by editing the /usr/local/emhttp/webGui/scripts/monitor script and comment out the following line 201: // if (!file_exists($smartDB) || (time()-filemtime($smartDB)>=$interval)) exec('/usr/sbin/update-smart-drivedb 1>/dev/null 2>&1'); See if that makes any change in your situation (these downloads are very low bandwidth), and I hope your hat is tasteful 40 hours since making this simple change and I have not had a single WEB GUI crash at all. Well as some of my other posts have indicated, I have been doing some maintenance today. This resulted in a Server reboot. Obviously that meant that the suggested change I made was lost (of course as it is not persistent) and I had forgotten. Well, what happened - BOOM - GUI starts crashing (after 1 hour of running ok again). I make the change again, and 3 hours later everything is fine! Sauce or not, I am sorry bonienl but I won't be eating that hat. I have no idea why a wget (albeit a very frequent repeat of it) is making the WEBGUI unstable in my case, BUT it is!! EDIT: I was thinking of just taking a copy of the changed file (with the suggested line commented out) and putting it on the flash drive and then in the GO file having a line to copy the version with the change over the one generated on every boot. Seems like there must be an easier way of doing this though. Any suggestions?
March 27, 201610 yr EDIT: I was thinking of just taking a copy of the changed file (with the suggested line commented out) and putting it on the flash drive and then in the GO file having a line to copy the version with the change over the one generated on every boot. Seems like there must be an easier way of doing this though. Any suggestions? Nope, that's how you would accomplish this. Only downside is that you have to remember to remove that line from the go file if/when you update unRaid versions (or the dynamix webUI) as the monitor script may change when you update. And it would appear that 6.2beta 20 already has that change in it: - dynamix: Get rid of SMART db update in monitor
Archived
This topic is now archived and is closed to further replies.