Emhttp segfaults, webgui not accessible


Recommended Posts

Hi,

 

Running 6B14. Tried to generate a windows KVM machine and the webgui stopped responding and emhttp process has died. If i try to restart it, this happens:

root@tank:/etc/rc.d# /usr/local/sbin/emhttp
Segmentation fault

And syslog shows this:

Apr  9 21:03:28 tank kernel: emhttp[27632]: segfault at 0 ip 00002b8ebad72d16 sp 00007fffe3d89408 error 4 in libc-2.17.so[2b8ebac3c000+1bf000]

 

Any idea can this be fixed without reboot?

 

If reboot is necessary, i would really like to know how to restart cleanly from the console? Dirty restart is not an option because parity check for 22TB takes forever :P

 

Hopefully someone has some ideas how to solve this!

Link to comment

If emhttp has crashed you can only reboot. There is no way to get it back and also no way to reboot "cleanly" from console.

 

So:

 

- Make sure you stop all writing to the array, stop every plugin or docker that you can stop without the unraid console.

 

- do a shutdown NOW from console

 

- reboot the system

 

It will boot up with a parity check, you can break it off if you want, but it is better to keep it running..

Link to comment

Depends on what you call clean... This basically makes sure all writing is stopped.. I think (but could be wrong) that a parity check would still start after tge reboot..

You are wrong.  If stopped as described in that link to the wiki instructions, the array will not need to perform a parity check upon restart.

 

The key command is

/root/mdcmd stop

which you'll only be able to perform successfully after un-mounting all the disks. (those are the first steps in the wiki link)

 

Joe L

Link to comment

Thank you for the tips. Was able to cleanly reboot the server from command line using jonathanm's link.

 

Cache was a PIA to unmount, had to stop docker containers and force umount with -l. After reboot checked the cache driver manually with btrfschk just to be sure.

 

Now running normally again and parity check was not needed.

Link to comment

Glad all worked out -- every time I see the segfault issue due to emhttp I have to wonder why this couldn't be as easy as it was with v4.7 => with 4.7 you could fairly easily restart emhttp with no reboot needed.  You did have to stop any active processes ... but then you could just restart emhttp and all was well.    Haven't been able to do this since v5, however -- so you need to keep the instructions for a clean shutdown from the console handy  :)

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.