I've had a few cases where the unMENU web interface has stopped responding after running a user script. The script in question is extremely simple and is used to start SABnzbd & Sickbeard:

 

#define USER_SCRIPT_LABEL Start SAB and SickBeard
#define USER_SCRIPT_DESCR Start SABnzbd and SickBeard (not CouchPotato or Headphones)

echo "Starting SABnzbd... "
su nobody -c "python /mnt/disk1/Apps/usenet/sabnzbd/SABnzbd.py -d"

echo "Starting SickBeard... "
su nobody -c "python /mnt/disk1/Apps/usenet/sickbeard/SickBeard.py -d"

echo "DONE!"

(No cache drive in case you're wondering)

 

Sometimes this works just fine, and sometimes the browser reports the page as unresponsive and unMENU doesn't come back up.

 

(Side note: Anyone else experience this? For what it's worth, both SAB and SickBeard start up just fine, and there's nothing in the syslog to indicate any issues at all...)

 

Now I'm having a similar issue with the main Management Utility site. Today I installed Headphones and during the initial scan of my 400+ artist folders, the site went down. I assume it's just a resource issue due to Headphones being not-particularly-well-written. The initial scan is taking FOREVER, and since the array is still up and everything appears functional, I'm inclined to just let it finish and reboot the system when it's done.

 

Here's the questions:

 

1. Is there a way via Telnet to restart the unMENU and Management Utility web sites?

2. If not, how do I gracefully reboot the system via Telnet (stop the array, then reboot)?

 

Also, if there's any other digging I can do to see what's up with the Mgt Utility, please let me know.

 

In case this helps: unRAID 5b14, Sempron 145, 2GB RAM.

 

-Rick

 

UPDATE: Management Utility is back! I've been refreshing every few minutes, and it suddenly loaded as if nothing happened. The last SysLog entry is:

 

Dec  9 13:37:41 <Name> afpd[3913]: dsi_stream_read: len:0, unexpected EOF

...which I believe is coming from my wife's Mac's TimeMachine backup (she just turned it on). I'm not sure if it's an issue, but I see these a lot when TM backups are running...

 

Either way, there's no mention in the logs of why the Mgt Utility went quiet. Also, still no word from unMENU.

When you run a user-script in unMENU it waits for all output of the invoked script before returning.  It is not that unMENU has stopped responding, it is your script that is still running.

Once your script finishes writing to its output, your unMENU page will return.

 

If you are starting script, make sure you redirect the standard output AND error output.  (and make sure it is not expecting input either)

 

You will need to disassociate the process you are starting from the unMENU user-script.  Easiest in many cases is to use "at"

In others, you can just put the script in the background, redirect the output and error output, and possible disassociate the script from its parent shell.

 

For each line you are invoking, try something like

su nobody -c "python /mnt/disk1/Apps/usenet/sabnzbd/SABnzbd.py -d" </dev/null >/dev/null 2>&1 &

 

or, if you want the log

su nobody -c "python /mnt/disk1/Apps/usenet/sabnzbd/SABnzbd.py -d" </dev/null >/tmp/SABlog 2>&1 &

 

if emhttp is stopping, odds are you are running out of memory and it is being killed by the OS since it was idle the longest.

Thanks Joe!

 

When emhttp is killed for lack of memory, is there an easy way to restart it, or do I need to reboot the system? Either way, I'll need the command(s) to do the start/reboot. Does that service also run unMENU?

 

I'll add the code to direct the output for my "su" calls. It's strange since I don't believe either of those commands shows any output when I run them via Putty, but I could be wrong about Sickbeard, since I think I've only tested SAB recently...

 

Thanks again!

Thanks Joe!

 

When emhttp is killed for lack of memory, is there an easy way to restart it, or do I need to reboot the system? Either way, I'll need the command(s) to do the start/reboot. Does that service also run unMENU?

 

I'll add the code to direct the output for my "su" calls. It's strange since I don't believe either of those commands shows any output when I run them via Putty, but I could be wrong about Sickbeard, since I think I've only tested SAB recently...

 

Thanks again!

To restart emhttp

killall emhttp

nohup emhttp >/dev/null 2>&1 &

Note: it is no longer possible to re-start emhttp in this way on any recent 5.X or subsequent version of unRAID.  You'll need to re-start the system, or, at the least, un-mount all the drive and stop the array.  (at least one user was able to re-start emhttp after doing these steps)  Unfortunately, if you've done this, it does take your array off-line for a time.

To restart emhttp

killall emhttp

nohup emhttp >/dev/null 2>&1 &

 

I've seen this enough recently that maybe it deserves an officially published button on the user scripts page of unmenu?

Perhaps right below the restart unmenu button?

Well, I suppose I could write one. The problem is, it won't do me much good: unMENU is still down on my system. Perhaps an entry on the Wiki somewhere instead?

 

Once Headphones finishes downloading information on every album by every artist in my library (sometime tomorrow at the current rate), I'm going to see if unMENU snaps out of it, and if not, run the killall/nohup commands.

 

-Rick