I am developing an application on a remote server.
I'm using Python and am connected via ssh with the specific extension.
I start debugging and everything seems to proceed normally but suddenly debugging stops and there is no reason (error or warning).
Can anyone suggest me where to look for the reason or how to trace the problem?
The script, executed outside VSCode, runs smoothly.
Thanks in advance.
in the end I found a possible cause and, therefore, the solution.
There is a problem with the sequence of imports and module import for MariaDB. By moving this import to the head, the problem was solved.
Related
No, I'm not talking about runserver listening for requests.
Whenever i run makemigrations, migrate or scripts i wrote using django-extensions command runscript, I need to stop the execution of the program before typing in another. This was not the case before restarting my PC this morning.
I'm building a small QR code ticketing app and it was working up until this morning. I fixed a bug regarding opencv since and the app is functional again, but this command line issue is bothering me. I'm going to have to make the /admin and scripts available to a few of my colleagues tomorrow and i'm afraid we won't know when the script running is actually done since it doesn't prompt or allow another command. Having a script executed terminated early because of this would be catastrophic.
whenever i run a command, the blank line not accepting input appears
There's way too much possible reasons why this could've happened; and it's impossible for anyone else to reproduce your scenario just based on what you described. This isn't a widespread issue, so it must something particular to do with your setup.
Run a debugger, like pudb or pdb to find out where the script is stuck on.
Or add a try-except block to catch KeyboardInterrupt to your manage.py and use traceback library to narrow down where it's stuck.
I have been attempting to run my python script as a service, and have followed the advice contained in several previous forum posts. However, these have not helped me thus far. Here is what I have attempted up until now:
Used an SMWinservice class that allowed me to install my Python script as a service. This solution, however, would not launch. If I would try to start it, I would receive an error message.
I have tried using NSSM with : nssm install myService pathToInterpreter PathToScript. Note, all files etc. can be found in the local directory of the PathToScript. For what its worth, I also tried using the GUI version of NSSM. When I rebooted my computer, it showed as "Paused" in task manager. I stopped it, and then tried to run it again, and I received an error. I have tried NSSM with both python.exe and pythonw.exe.
I suspect that a possible source of error is the fact that my program uses a text file as a configuration file. This configuration file has been coded as being in my local working directory. However, I wouldn't think this would be an issue with NSSM. I know for a fact that my program will completely exit, using the exit command, if the configuration file is not found.
I was thinking of doing a batch file and starting the batch file with the script and running it like that, but I prefer a service since it can monitor the process, can restart it, or windows can notify me via email if there is an issue with my service.
For completeness, I should also mention that the program runs without issue outside of a service. For the reason that the program runs as expected, I decided to not post the code, unless someone would like to see it for whatever reason.
I have a multi-threaded Bottle/Python web application that only occasionally hangs. The source can be downloaded here: https://github.com/whbrewer/spc
I've been trying to figure out what is causing the hang, but since it only happens very occasionally and I have not yet figured out how to reproduce it, I try to spend some time whenever it hangs to discover what is causing the problem. I have tried attaching a debugger to the running process using:
gdb /usr/bin/python -p 32489
but this only gives me the libc traceback such as:
0x00007fd2adbdb0fc in __libc_waitpid (pid=32490, stat_loc=stat_loc#entry=0x7ffd8aac545c,
options=0) at ../sysdeps/unix/sysv/linux/waitpid.c:31
31 return INLINE_SYSCALL (wait4, 4, pid, stat_loc, options, NULL);
From this output, I was able to find a similarly asked question which provided some useful advice, but ultimately did not help solve the problem. However, from reading another related informative post, I discovered that the Python debugger PDB can be used to solve this problem. So, my question is, how would I go about implementing PDB in a Python/Bottle application so when it occasionally hangs, I can get a python traceback?
One thing I have noted, is that when the hang happens, it seems the server thread turns into a zombie process, so it shows a defunc python process, while the other threads seem to continue to run. I have tried to use different web servers with Bottle, such as cherrypy and rocket, but both gave the same result.
I have a situation where if I run Apache with wsgi (now uninstalled), a test website works, but running the same server with runserver 0.0.0.0:8080 gives ERR_CONNECTION_REFUSED from local or remote (even with the apache2 service stopped).
Edit: I don't think it's Apache, I've reproduced the problem on a clean server with no Apache installed, so unless Apache somehow modified something under source control it's not that
My knowledge of web details is hazy, I don't even know where to troubleshoot this problem - the devserver runs (runserver prints as expected and doesn't give any errors) but never receives a request, I have nothing in iptables.
Sorry for anyone who read this, it would probably have been impossible to solve given my supplied information.
What had actually happened was that I'd been having to modify my wsgi.py script in order to make it happy inside the Apache server, and I'd added a line which said "os.system('/bin/bash --rcfile )" to try and make sure that when running inside apache it got the virtualenv activated.
This line must have been causing some strange problem, another symptom was that I realised when I was running "runserver", it wasn't crashing the the python process was backgrounding itself, where normally it runs inside that console window.
Thanks everyone who asked questions helping me debug!
SEE EDITS
I'm trying to get the latest version of PyCharm to successfully debug Django running inside Docker. However I'm having trouble setting up the remote python interpreter and I get an error as soon as I try to start the debugger.
Can't run remote python interpreter: com.github.dockerjava.api.exception.InternalServerErrorException: {"message":"the working directory 'C:/Program Files (x86)/JetBrains/PyCharm 171.2613.10/jre64/jre/bin' is invalid, it needs to be an absolute path"}
The path, in my eyes looks pretty absolute, so I'm guessing its something else. I'm not even sure who or what is causing the error. The docker container (because of the JSON response) or PyCharm.
Running
PyCharm 2017.1
Docker for Windows (docker version 1.13.0)
Any thought of what I might be missing/having problem with?
Edit
Forgot to include my settings from PyCharm on how I set up the remote interpreter.
I get no errors with the above settings
Edit 2
It looked like the "Django project root" had accidentally been set to the incorrect path above. So that is fixed. My problem now is that when I run the Run/Debug Configuration it tries to start the server again, which is already running inside the docker container. Is there no way to attach to the already running python process?
Edit 3
I've now managed to get a "success" message when starting the debugger (PyCharms Python Remote Debugger) and starting the server after. However I seems like the debugger stops listening after 1 second (or less). My theory is that the debugger looses connection after it has passed the pydevd.settrace() function call. I have placed the following code (of the top of my head) at the bottom of manage.py:
sys.path.append('pycharm-debug.egg')
import pydevd
pydevd.settrace('192.168.1.100', port=21000)
What am I missing?
EDIT 4
After investigating further I now seem to successfully connect the debugger on server startup. However, if the pydevd.settrace(....) function call is present the server never actually starts. The startup seems to freeze/stop on python manage.py runserver 0.0.0.0:8000. As soon as I remove the settrace line. The server starts without issue. Any ideas?
I also get this message when the server is starting:
warning: Debugger speedups using cython not found. Run '"/usr/local/bin/python" "/usr/local/lib/python3.5/site-packages/setup_cython.py" build_ext --inplace' to build.
The problem is that I can't run the command listed in the message because the file setup_cython doesn't exist.
You're right! It really don't start the runserver process, but I believe it's not because isn't working, but because it is.
See, when you successfully connected the pydevd settrace with the debugger server you had to configure on PyCharm it already worked, at least it worked for me.
I believe the reason runserver isn't working is because the warning created by the missing cython is stopping the debugger, the only thing you have to do is tell it to keep running and jump that warning clicking on the green right-pointing arrow to do so.
PS.
I'm debugging a django application running on docker (docker-machine), the host IP, in that case is 192.168.99.1
#!/usr/bin/env python
import os
import sys
if __name__ == "__main__":
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "helpdesk.settings")
from django.core.management import execute_from_command_line
sys.path.append('pycharm-debug.egg')
import pydevd
pydevd.settrace('192.168.99.1', port=3000, stdoutToServer=True, stderrToServer=True)
execute_from_command_line(sys.argv)
Hope I helped!
I have the same quesiton
I had solved it by editing the pycharm Interpreter
you can add some config to the "Path mappings" as follows
before the "=" , write your local code path
after the "=" , wirte your cloud server code path
Interpreter-config.png
I only change this， it works！！！
Hope that can help you~