I have a Django REST API running on an UBUNTU 20.04 server, with a sqlite database.
Everything has been working for weeks with no issue.
Today, after pulling small changes to my code (changes in my settings.py file), I've tried to restart the GUNICORN server with SUPERVISOR as usual with:
sudo supervisorctl restart <MyAppName>
but I get an error message :
<MyAppName>-gunicorn: ERROR (spawn error)
In /var/log/supervisor.supervisor.log, I can only see that error message :
exited: <MyApp>-gunicorn (exit status 3; not expected)
I can find no way to have it working again (I've even tried to restart the server).
The strange thing is that when I manually launch gunicorn with :
/home/<myname>/env/bin/gunicorn <MyApp>.wsgi
I have no error message and my server works perfectly(requests are served to my app).
How can I know the reason for the supervisor spawn error ?
Related
for a lab, I was asked to created a python file that would be run as a service. After creating that file and entering the code provided, my system suddenly crashed. I tried rebooting it on multiple occasions, but it still won't work. (I will try to link images on the error message.)
Example of error message: [Failed] Failed to start Network Time Synchronization
I tried booting the system on recovery mode, but after entering my root password, it only displays this message ("Debian GNU/Linux 10 Velvet ttyl \n Velvet login: ") and I don't know what to do after. I try asking the teacher, but we couldn't figure it out either.
I've recently setup and installed (after much finicking around to get around the seemingly common SSL error) the Mario Strasser TPM emulator.
Setting it up to run with modprobe tpmd_dev and then tpmd worked fine, however, once it was running I wanted to begin working on some code to interact with it and ran the test_tddl file, only to find that it fails to open the /dev/tpm file. after a little digging around I've found that it's a failure due to a sock_connect() call fails. Have I gone wrong with setting up the emulator somewhere? I'm running on ubuntu 16.04 on a virtual box VM
The error given upon running test_tddl is Error: Tddli_Open() failed: operation failed (0002)
and the error given in dmesg isError: sock_connect() failed: -2
Im an idiot, if anyone else runs into this problem, ensure that your running both tpmd and test_tddl as root, or else the programs will be unable to open the socket required.
I'm suffering from server problem on both perfect and vapor ..
The server working for only one time , and once after i update the project and rebuild it, the server response does not update any more.
I got this error ... from vapor in Xcode
No command supplied, defaulting to serve...
Starting server on 0.0.0.0:8080
Serve error: Sockets Error: Failed trying to bind to the address
Identifier: Sockets.SocketsError.bindFailed
Program ended with exit code: 0
I googled alot , but did not figure out the problem
Finally : when i restart the mac , the server worked good only for one time , and the problem returned the same .
Seems like a process is using port 8080. Try running lsof -i :8080 from the terminal and kill it's PID with kill -9 PID
My problem solved after 2 days of searching by removing Xcode and reinstalling it .. Although Xcode was working well and i have just installed it one month before , but after i tested everything i tried hopelessly to do that and it worked .. seems frustrating , but it worth mentioning that for anyone who would facing that thing .
I am deploying my Flask application on WebFaction. I am using flask-socketio which has lead me to deploying it with a Custom Websocket App (listening on port). Flask-socketio's instructs me to deploy my app by starting the serving with the call socketio.run(app, port= < port_listening_on >) in my main python script. I have installed eventlet on the server so socketio.run should run the app on the eventlet web server.
I can call python < app >.py and all works great – server runs, can view it at the domain, sockets working, etc. My problems start when I attempt to turn this into a long running process. I've been advised to use supervisor which I have installed and configured on my webapp following these instructions: https://community.webfaction.com/questions/18483/how-do-i-install-and-use-supervisord-to-control-long-running-processes
The problem is once I actually add the command for supervisor to run my app it errors with:
Exited too quickly
My log states the above error as well as:
(exit status 1; not expected)
In my supervisor config file I currently have the following program config:
[program:<prog_name>]
command=/usr/bin/python2.7 /home/<user>/webapps/<app_name>/<app>.py
autostart=true
autorestart=true
I have tried a removing and adding settings but it all leads to the same FATAL error.
So this is what part of my supervisor config looks like, I'm using gunicorn to run my flask app.
Also, I'm logging errors to a file from the supervisor config, so if you do that, it might help you see why it's not starting correctly.
[program:gunicorn]
command=/juzten/venv/bin/gunicorn run:app --preload -p rocket.pid -b 0.0.0.0:5000 --access-logfile "-"
directory=/juzten/app-folder-name
user=juzten
autostart=true
autorestart=unexpected
stdout_logfile=/juzten/gunicorn.log
stderr_logfile=/juzten/gunicorn.log
I have stopped a virtual machine with CentOS running an instance of Context Broker. Upon relaunching the system with the enabler, the latter gives a Fatal Error. See the below log:
# contextBroker
INFO#13:18:32 contextBroker.cpp[1348]: Orion Context Broker is running
INFO#13:18:32 mongoGlobal.cpp[164]: Successful connection to database
INFO#13:18:32 contextBroker.cpp[1157]: Connected to mongo at localhost:orion
INFO#13:18:32 mongoGlobal.cpp[483]: Database Operation Successful ({ conditions.type: "ONTIMEINTERVAL" })
INFO#13:18:32 rest.cpp[901]: Fatal Error (error starting REST interface)
I'm working on the 4.1.2 version of Orion, CentOS 6 running in VirtualBox. Running with su because I get a permission denied on a log file error. For info, I have enabled bridging network connection just before the VM reboot.
Is it the fact that the broker was not closed correctly that there is something blocking its restart? (PS. yes I know that there is a nearly exact same error message in the administration guide, but I don't see any solutions there)
Thank you!
EDIT: one solution that works is uninstalling the contextBroker package and installing it again. I wish there was a cleaner way!
EDIT: this problem reproduces every time I kill the contextBroker application - then every time restarts don't help, reinstalling the package does.
Make sure there is no other instance of the broker running (ps aux | grep contextBroker), using the same port.
If there is another instance of the broker running, then the port will be taken and the REST initialization will fail.
About running as root because of log-file permissions ... Why not simply change the owner of the log-file instead?