0

I am having a cherrypy application which calls a subprocess (subprocess.Popen), it works fine most of the time but sometimes it does not work. When I restart the server, the subprocess.popen get called and works fine. Is there a way to monitor threads in cherrypy and check why the subprocess.popen was not called.

Update: The thread continues the rest part of the code and I could the response, only problem is the subprocess is not called

sample code

def fn_test(self,**args):
    #return args['md5'].split()[0]
    final_html="the complete html"
    for i in ['ab','cd','ef']:

        if args.has_key(i):
            cherrypy.session[i]='checked'
        else:

            cherrypy.session[i]=''



    subprocess.Popen(["python","test.py",'test','aval','bval'])
    return final_html
user1865928
  • 47
  • 1
  • 1
  • 6
  • 1
    Can you show a simplified version of your code that reproduces the problem? – saaj May 12 '15 at 09:27
  • saaj sorry for the delay in reply, I have added a sample code, please let me know if you have any questions, also the problem I have is subprocess.popen does not run at times – user1865928 May 13 '15 at 10:02
  • Tell more about what the subprocess does. How do you find out it hasn't been called? I see no interference with return value. What is the purpose of the subprocess? Do you have logging in the module so you can reason about its correctness? Why can't you import the module and use it directly? – saaj May 13 '15 at 11:05
  • Hi Saaj, sorry about delayed resposne, the subprocess does a background task and is used later. The return value polls for the background job results and updated through ajax, It's designed to work as a backhround task so importing makes things complicated – user1865928 May 16 '15 at 20:12

1 Answers1

0

For simple and occasional background tasks I recommend cherrypy.process.plugins.BackgroundTask. Take a look at this question for a complete example and other general consideration about background tasks.

Specifically, treating the subprocess issue, make sure you can reason about your background code's correctness. At least make several logging entries on start, stop and optionally before/after significant state changes in the module. Also for debugging propose replace your command with something really simple that is guaranteed to be bug-free. For example, date >> date.log. Then it'll be clear whether the issue originates from background module's flaw or from a process spawning issue.

Community
  • 1
  • 1
saaj
  • 23,253
  • 3
  • 104
  • 105
  • saaj,Thanks a lot,I will try and implement it this way. Do you know if there is any partuicular readon that background process will not be called from cherrypy – user1865928 May 18 '15 at 11:59
  • @user1865928 A CherryPy worker thread is a normal thread, that once started lives until CherryPy's stop or restart. So I don't see fundamental reason why spawning a process shouldn't work. You may want to look at [CherryPy's bugtracker](https://bitbucket.org/cherrypy/cherrypy/issues?status=new&status=open) if you think it's on CherryPy's side. Though I don't think it's likely. – saaj May 18 '15 at 13:09