Parity check running - unable to access the Web UI

So I started a parity check last night and it immediately became apparent that the Web UI was hanging.  It's still running this morning but still no access...

 

Looking around I can runfrom the command line:

/root/mdcmd status | egrep "mdResync|mdState|sbSync

 

But from that I have no idea how long is left.  Any ideas?

 

@Limetech support:  I see I am not the only one with this issue with the Web UI hanging on parity check:

http://lime-technology.com/forum/index.php?topic=37442.msg346205#msg346205

 

& on Unraid 5:

http://lime-technology.com/forum/index.php?topic=35539.msg331008#msg331008

http://lime-technology.com/forum/index.php?topic=26989.msg236528#msg236528

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

Would it not be worth now to start recommending that on v6.0 that the 'diagnostics' command is run as this is no more effort and provides more than just the syslog?  It also creates a ZIP file which is convenient for uploading to the forum.

Will sort this out tonight.

I would say in general though, my (limited) experience with Unraid 6 is that the Web UI flakes out a lot more than with 5.

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

Would it not be worth now to start recommending that on v6.0 that the 'diagnostics' command is run as this is no more effort and provides more than just the syslog?  It also creates a ZIP file which is convenient for uploading to the forum.

 

He says "webUI is hanging" meaning he probably can't get to that Diagnostics tool.  Besides probably the syslog is enough to tell the tale in this case.

Will sort this out tonight.

I would say in general though, my (limited) experience with Unraid 6 is that the Web UI flakes out a lot more than with 5.

Most would say the opposite.  There is a whole lot more complexity though.

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

Would it not be worth now to start recommending that on v6.0 that the 'diagnostics' command is run as this is no more effort and provides more than just the syslog?  It also creates a ZIP file which is convenient for uploading to the forum.

 

He says "webUI is hanging" meaning he probably can't get to that Diagnostics tool.  Besides probably the syslog is enough to tell the tale in this case.

 

Correct I can't reach the Web UI at all, either last night or this morning.  SSH is no problem.

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

Would it not be worth now to start recommending that on v6.0 that the 'diagnostics' command is run as this is no more effort and provides more than just the syslog?  It also creates a ZIP file which is convenient for uploading to the forum.

 

He says "webUI is hanging" meaning he probably can't get to that Diagnostics tool.  Besides probably the syslog is enough to tell the tale in this case.

I did not suggest going to the Diagnostics tool in the GUI.  I suggested typing the 'diagnostics' command from the CLI which achieves the same effect.  If it is possible to type in the suggested 'cp' command then it is also possible to type the 'diagnostics' command.  Not that the syslog might not be sufficient in this case but asking for the diagnostics output can be a standard response regardless of the problem type and in some cases that extra information might be important so why not get it up front.

Is top command reporting emhttp @100% CPU usage? 

top command reports emhttp @100% CPU usage? 

That suggests some sort of 'race' condition.  How it might be identified I have no idea.

top command reports emhttp @100% CPU usage? 

That suggests some sort of 'race' condition.  How it might be identified I have no idea.

 

Sorry, I was just askin'... 

 

BUT I think it could be this way... If so, Bonienl suggested CLI commands in my similar thread could be usefull to identify issue causes... https://lime-technology.com/forum/index.php?topic=40353.0

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

 

See attached. Web UI still not reachable.

Let me know if you need anything else.

syslog.zip

cp /var/log/syslog /boot/syslog.txt

 

Now your system log is in the root of your flash.  Access it via network and post.

 

See attached. Web UI still not reachable.

Let me know if you need anything else.

 

There is an issue with one of the 3rd party plugins, I'd guess 'unassigned devices'.  Boot in safe mode and no more problems.

Ok, thanks.  The parity check is still on going, I presume I should wait for this to finish first?

 

And "safe" mode - how do I do that? - I have no monitor attached.

 

 

Update on this.  I believe the parity check finished so I restarted the server.  Everything appeared to be in order, yet after starting to rsync some data back on to the server, the web UI is hanging again.  So I guess it must be one of the plugins that is playing up.  Either assigned devices or powerdown.  Any help appreciated.

syslog_2.txt

Update:

 

I removed both plug-ins; powerdown & unassigned devices, as well as disabling docker.

All went well, Web UI reacted and performed as one would expect.

 

Added docker back in and a few containers

No changes, everything still going great

 

Powerdown reinstalled

Again, everything fine after more than a week of playing around and no lock-ups

 

Last couple of days, reinstalled the unassigned devices plugin

5 minutes of navigating various menus, changing some settings etc... and bam, Web UI is down again

 

I see on there are various other users facing Web UI-responsiveness issues on the front page of General Support.  How can I provide more debugging / help on this issue?

Post in the thread devoted to the unassigned devices plugin.