I've been working on and maintaining a PLG for pyTivo but have recently run into an odd issue that I can't find a resolution for.  I'm hoping someone here sees this and can help.

 

On the unraid menus, I provide buttons to stop, restart, etc the process (similar to sabnzbd and other influencer plugins for which I heavily based the html).  These buttons typically call some function in /etc/rc.d/rc.pyTivo and everything works, except for 'start'.  This starts the process and displays my "OK" indicating the rc script completed but the unraid screen doesn't refresh like normal as with the other commands.  Instead it hangs and appears waiting for something to finish.  If I manually refresh the browser or open a different website, the process gets killed.  However, I can start the process from the shell, using rc.pyTivo, with no issues.  Also, if I comment out the line below from rc.pyTivo --> pytivo_start(), the unraid screens will refresh, but obviously the process won't start.  So I'm thinking the problem lies in this line:

python $INSTALLDIR/pyTivo.py > $LOG_FILE 2>&1 &

 

I've spent most of the weekend significantly improving this PLG but am completely baffled by this behavior.  If some kind soul could take a look and help me out, I and many other pyTivo users would be very thankful.

 

https://dl.dropbox.com/u/40493373/pyTivo/pyTivo.plg

 

I dunno if it would work, but what about nohup?  If you put "nohup" before any command and an ampersand (&) afterwards, the command will run in the background until it is complete. Your command prompt will return immediately.  I used it in start scripts for PS3MS and it worked.

 

Here's the PS3MS example.  nohup ./PMS.sh >/dev/null 2>&1 &

 

I'm new to linux, but this just sounded similar to my issue with the application I was working on.

 

Good luck.

I played with nohup but I recall getting the same behavior.  I will certainly try again tonight to verify.  Thanks for the suggestion.

you can also try something to the effect of:

 

echo "python $INSTALLDIR/pyTivo.py > $LOG_FILE 2>&1 &" | at now

 

You may be able to leave of the last '&'

nohup nowork

 

... but 'at' did.  I swear I played with that yesterday and it didn't work, but it does now.  Works with or without the '&' which makes sense since 'at' already starts things in the background.  Thanks prostuff1!