I have a python script which is threaded and runs on our server node . The Problem is that the script gets stuck/hanged without any trace.
How to check where the script is hanging as it doesn't print anything
Take a look at the hanging_threads module (available from PyPI) - It might give you some pointers on where your code gets stuck. However it is prone to false positives (e.g. if your script waits for a network connection).
Related
In jupyter, when an error occurs, we can continuously debug the error with the command %debug. I want to know if there is the similar way in running python script (.py) in the shell.
I know that I can use pdb to make some break points, but I just want to know the way without such a pre-processing (because re-running the code until the error costs a lot of time).
In general, no: it depends on "the shell" that you are running. Jupyter launches with a lot of instrumentation in support of its debugger, assuming that you're using Jupyter because you want those capabilities at the ready.
I presume that you're using some UNIX shell (since you mention pdb); implicitly loading superfluous software is antithetical to the UNIX philosophy.
I think that what you'll need is one of the "after" debugger modes, although that will still leave you without information from just before the error point: those packages cannot do much to trace the history of problem variables.
I recently started using Python. I realized that even the simplest program starts a Python process that never ends and causes my computer to overheat if I don't manually kill that process.
I've even seen multiple Python processes running at the same time after running a few easy Python programs (Hello, World!) in a row.
I updated to the latest Python version (Python 3.9.3), installed all the Certificates, and tested a few different programs to see if it happens every time—it does. I am using VSC as the IDE but the same situation happens even if I use IDLE.
My questions are: Is this an interpreter issue or a Mac issue? Can it be fixed?
Thank you very much.
I'm writing a script in Python for Linux that should suspend process when given conditions are met and later resume it. To do so I'm using psutil (http://code.google.com/p/psutil).
The problem I encountered is rather strange. When I use python command line, everything works fine - process is suspended and later resumed. However, when I use the same function in a script file and then I try to run it, it throws exception:
AttributeError: 'Process' object has no attribute 'suspend'
Snippet of code:
p = psutil.Process(19931)
p.suspend()
print 'suspended'
time.sleep(10)
p.resume()
print 'resumed'
Of course 19931 is typed PID of the process I've started in background and want it to be suspended.
Does anyone have some ideas or hints? Psutil is the newest version installed from Google code.
I know its an old entry but for the ones who encountered this problem recently,
this code works fine for me (Python 3.7.3) :
psutil.Process(pid=19931).suspend()
And similarly
psutil.Process(pid=19931).resume()
But you have to be sure that referred process is still alive.
The first thing I would suspect when Python behaves differently under the interactive shell and executing a script would be running different versions of Python. This can easily happen when you point to an interpreter in your script file with something like:
#!/usr/bin/python
This is a long shot since, according to the psutil website, it's supposed to work well with Python versions from 2.4 to 3.3. Also, your snippet works fine on my machine (kernel 2.6.32, Python 2.6.6).
I'm trying to run a python script from a python program by kicking it off from subprocess (The reason is that the main program has to have exited when the script runs, with a combination of wx.CallAfter and Close). However when the script runs I get an error on line 1 with ImportError: No module named os which makes me think it's something to do with the PythonPath, but I can run the script just fine from a terminal.
Why can't the script see any core modules when run this way?
Edit:
The line in question is:
wx.CallAfter(subprocess.Popen,'python %s "%s" %s %s'%(os.path.join(BASE_DIR,"updatecopy.py"),BASE_DIR,pos[0],pos[1]),shell=True)
BASE_DIR is just the directory that the script lives in.
subprocess is there because os.exec* has been deprecated so I wouldn't suggest using that in place of Popen as someone suggested.
I've seen this issue crop up when running from a frozen process. If that is the case then you're most likely inheriting a weird environment for the new python process.
Most frozen scripts will be trying to run from a zip file, in which case it's no wonder that Python can't find anything, it's all trapped in a zip file :)
If this is the situation then try running using the python executable that you are using to run the frozen script. It should be able to deal with the special environment.
Maybe you could use os.execv instead of Popen.
From os/python docs:
These functions all execute a new program, replacing the current process; they do not return. On Unix, the new executable is loaded into the current process, and will have the same process id as the caller. Errors will be reported as OSError exceptions.
(emphasis mine)
i have a py2app application, which runs an appscript using py-appscript. the Applescript code is this one line:
app('Finder').update(<file alias of a certain file>)
What this normally does is update a file's preview in Finder. It works most of the time, except for Leopard. In Leopard, everytime that script is executed, instead of updating the file, it starts a new instance of Finder. What am I doing wrong? The app was built on the same machine (the Leopard).
Seeing as how py-appscript is a layer between python and the application you are scripting via Applescript, I would suggest porting the statement to pure Applescript and see if it works there. There are a lot of things that can go wrong with Applescript (and your statement alone) to begin with and it's not obvious what is the expected before with py-appscript when an error occurs.