Hi guys,

i had a crash of emhttp today, after i've clicked on the compute space under the share tab, the process emhttp and unmenu crashed.

Now i was able to restart unmenu but if i try to start emhttp it dosn't start.

I've attached the logs.

 

Thank you,

Fabio.

emhttp.txt

Ok, i was able to reproduce the bug, to let emhttp crash, click on "compute...", and BEFORE it finish click immediately on "compute..." on another share.

 

ADD: Also if u kill emhttp and restart it, u get the same problem.

It seems that emhttp try to rmmod and modprobe md_mod, it fails and so it don't start.

But, if u launch: "/etc/rc.d/rc.unRAID stop" emhttp will be able to rmmod the module and start without problem.

 

Fabio.

You clicked on a greyed-out link?  LOL, turns out there is no way to disable all links on a page in a browser-independent manner, so when a background utility is running (such as calculating share disk usage), all links are just colored "grey" instead of being actually disabled 

 

But you have encountered two issues.  First that clicking on a link while background util is running should not kill the webGui (emhttp) process - this has been fixed in 5.0-beta5.  Second, is the kernel oops that results in trying to restart emhttp.  This is not a normal activity and I may or may not fix it.

You might be able to push an overly large DIV (saying In Process/In Progress or something similar) in front of the entire page to make all those links unclickable. It's one nasty hack, but if it works for a financial institution it should work for unRAID. 

Second, is the kernel oops that results in trying to restart emhttp.  This is not a normal activity and I may or may not fix it.

 

I think that the problem is the rmmod of md_mod module that fails, is it necessary to rmmod and then modprobe it again?

 

Thank you,

Fabio.

The Post / redirect / get pattern is the pattern that solves this problem.

 

http://en.wikipedia.org/wiki/Post/Redirect/Get