October 14, 201312 yr I build a new machine and tested the parity swap feature. After some hours of copying the GUI went unresponsive. unMENU was still reachable, samba was still working. I can do further tests to narrow the issue down if requested. See attached syslog. syslog-20131013-212127.zip
October 15, 201312 yr Author Started the parity-swap again in safe mode. Will be back when it's finished. Although I don't think the "unresponsive GUI" issue is related to any plugin.
October 15, 201312 yr Does "parity swap" mean you changed your parity drive? From the excerpt of the syslog below it looks like the copy process got to 99% and stayed that way for over an hour at which point you initiated the power down, right? Perhaps your system ran out of memory for the process?? There's no indication of the emhttp process failing. There's some debate about RAM sizing when you get around 4GB and up. Did all disk operation cease during that hour and that's what made you decide to shut it down? I seem to recall reading on this forum about webGUI responsiveness problems during parity rebuilds, but I can't be sure. Maybe there was some additional "clean-up" at the end of the process that caused the problem. Sorry, I'm just throwing out a few ideas here........... Oct 13 11:04:46 ALI kernel: md: disk1 replaced Oct 13 11:04:46 ALI kernel: mdcmd (3): import 2 0,0 Oct 13 11:05:10 ALI emhttp: writing GPT on disk (sde), with partition 1 offset 64, erased: 0 Oct 13 11:05:10 ALI emhttp: shcmd (84): sgdisk -Z /dev/sde &> /dev/null Oct 13 11:05:11 ALI emhttp: shcmd (85): sgdisk -o -a 64 -n 1:64:0 /dev/sde |& logger Oct 13 11:05:11 ALI kernel: sde: sde1 Oct 13 11:05:12 ALI kernel: sde: sde1 Oct 13 11:05:12 ALI logger: Creating new GPT entries. Oct 13 11:05:12 ALI logger: The operation has completed successfully. Oct 13 11:05:12 ALI emhttp: shcmd (86): udevadm settle Oct 13 11:05:13 ALI emhttp: copy: disk1 to disk0 Oct 13 11:09:50 ALI emhttp: copy: 1% complete Oct 13 11:14:26 ALI emhttp: copy: 2% complete Oct 13 11:19:03 ALI emhttp: copy: 3% complete ............a lot of copying entries ............................... Oct 13 20:26:12 [/color]ALI emhttp: copy: 99% complete Oct 13 21:21:13[/color] ALI logger: Powerdown initiated Oct 13 21:21:13 ALI rc.unRAID[3385]: Stopping unRAID.
October 15, 201312 yr Author Yes, I was testing the parity-swap feature because there were some questions about how to start the procedure. During the process I occasionally checked the status of unraid. After reaching 99% the GUI was unresponsive for about an hour and then I decided to restart the server. The system was still operational. Samba was working and the unMENU add-on was also working. I don't know whether they would if I ran out of memory? After the reboot, I saw that the parity-swap did not succeed. Apart from this parity-swap process there was no other load on the machine. I have already run a preclear of 4x4TB drives simultaneusly for over 40 hours. The rig seems stable to me. Unfortunately I read about many unresponsive GUI's in the forum and I also have had some on this machine and on my other server too.
October 15, 201312 yr I won't say this is a solution, here's a link to a thread, http://lime-technology.com/forum/index.php?topic=29408.msg264499#msg264499, in which I posed a question about the use of this code in the GO file: pgrep -f "/usr/local/sbin/emhttp" | while read PID; do echo -1000 > /proc/$PID/oom_score_adj; done The theory is you are protecting emhttp from getting closed. As you can see the response was somewhat cold I bring it up for consideration in light of your concerns, posted elsewhere, about the stability of emhttp.
October 15, 201312 yr Another link entitled, "HowTo: Restart emhttp WebUI without rebooting" http://lime-technology.com/forum/index.php?topic=27085.15 Maybe that will help?
October 15, 201312 yr Author I read that last thread already. If I have to do that I'm probably faster by simply rebooting. Next time when the GUI fails, I will check memory stats and emhttp process status. http://lime-technology.com/forum/index.php?topic=29408.msg264499#msg264499
October 16, 201312 yr Author Parity-swap successfully finished in safe mode. GUI still alive (responsive) after that. At the moment another parity-swap is running in normal mode. unMENU is the only add-on installed.
October 17, 201312 yr Author Parity swap successfully finished in normal mode. GUI still alive (responsive) after that. So it's still not clear what's causing the GUI going unresponsive.
October 17, 201312 yr Parity swap successfully finished in normal mode. GUI still alive (responsive) after that. So it's still not clear what's causing the GUI going unresponsive. An add-on is causing the issue. Isolate the problem add-on by enabling only 50% of the add-ons.
October 21, 201312 yr Author As already mentioned. There is only unMENU and the new unRAID GUI running on this machine. Btw, it's not so easy to isolate a randomly appearing fault...
Archived
This topic is now archived and is closed to further replies.