I'm using gunicorn 20.1.0 (with uvicorn workers for FastAPI).
I'm trying to increase the default timeout, but I still get CRITICAL WORKER TIMEOUT after ~90 sec, instead of 180 secs, value I configured via CLI:
gunicorn app.web_api.application:api --workers ${NUM_WORKERS} --worker-class uvicorn.workers.UvicornWorker --timeout 180 --bind 0.0.0.0:8000
Any idea ?
Related
I have 2 home PCs with windows 10. I want to create test ipfs private network between 2 nodes.
I downloaded go-ipfs.
ipfs version 0.6.0
I executed
ipfs init
ipfs bootstrap rm --all
I made swarm.key and added node to config.
ipfs bootstrap add /ip4/62.122.132.55/tcp/4001/ipfs/QmYY9U3JFuMykjRjKd1jg6aPCmcf2UYpbaS8fHpwkAVvia
I checked if port 4001 is listening.
TCP [::]:4001 [::]:0 LISTENING
The same I made on the second node.
I started nodes
ipfs daemon
The result was
Initializing daemon...
go-ipfs version: 0.6.0
Repo version: 10
System version: amd64/windows
Golang version: go1.14.4
Swarm is limited to private network of peers with the swarm key
Swarm key fingerprint: 4c11fea5d8ab67ccf08b22a4ee220db3
Swarm listening on /ip4/127.0.0.1/tcp/4001
Swarm listening on /ip4/192.168.1.102/tcp/4001
Swarm listening on /ip6/::1/tcp/4001
Swarm listening on /p2p-circuit
Swarm announcing /ip4/127.0.0.1/tcp/4001
Swarm announcing /ip4/192.168.1.102/tcp/4001
Swarm announcing /ip6/::1/tcp/4001
API server listening on /ip4/127.0.0.1/tcp/5001
WebUI: http://127.0.0.1:5001/webui
Gateway (readonly) server listening on /ip4/127.0.0.1/tcp/8080
Daemon is ready
On second node I tried execute
c:\ipfs>ipfs swarm connect /ip4/62.122.132.55/tcp/4001/ipfs/QmYY9U3JFuMykjRjKd1jg6aPCmcf2UYpbaS8fHpwkAVvia
Error: connect QmYY9U3JFuMykjRjKd1jg6aPCmcf2UYpbaS8fHpwkAVvia failure: \
failed to dial QmYY9U3JFuMykjRjKd1jg6aPCmcf2UYpbaS8fHpwkAVvia: all dials failed
* [/ip4/62.122.132.55/tcp/4001] dial tcp4 0.0.0.0:4001->62.122.132.55:4001: i/o timeout
c:\ipfs>
After some time daemon showed
Daemon is ready
2020-07-19T08:43:50.560+0300 [31mERROR[0m reprovider.simple simple/reprovide.go:108 \
failed to reprovide: failed to find any peer in table
What I missed?
can you run the following commands?
ipfs id
https://docs.ipfs.io/reference/cli/#ipfs-id
ipfs swarm peers
https://docs.ipfs.io/reference/cli/#ipfs-swarm-peers
ipfs boostrap list
https://docs.ipfs.io/reference/cli/#ipfs-bootstrap
SOME BACKGROUND:
I have created a django app and I am at the point where I want to deploy it. I have looked at multiple options including wsgi but since the new mac os update came about, I can not install mod_wsgi because I do not have apxs or apxs2 on my computer, (Some discussion on web about rights to write in files, If you know more and would like to explain, please do.)
However, I looked into other options to try to deploy the app and I want to use Heroku. I have followed the dev guide for Django deployment until I reached the part where I test using "heroku local web".
THE ISSUE
The problem stems from here because the local mysql server uses the same port that the gunicorn is also trying to use. I have found similar posts on stackoverflow about 'connections in use' but none have shown how to change ports for gunicorn. I have found some open ports available on my localhost but everytime I try to change the mysql ports to those, the connection times out. Therefore, I would like to know how to change the port the Gunicorn connects to so it does not try to connect to the same default port as the mysql which is 3306.
I was serving the django project with the server it came with and the database I am using is mysql for local production. I am trying to connect locally with gunicorn and Heroku now because I feel that if this goes right locally it will probably go right when I attempt to put the project online.
ERROR GIVEN
10:38:52 PM web.1 | [2017-01-08 22:38:52 -0500] [83200] [ERROR] Connection in use: ('0.0.0.0', 3306)
10:38:52 PM web.1 | [2017-01-08 22:38:52 -0500] [83200] [ERROR] Retrying in 1 second.
10:38:53 PM web.1 | [2017-01-08 22:38:53 -0500] [83200] [ERROR] Connection in use: ('0.0.0.0', 3306)
10:38:53 PM web.1 | [2017-01-08 22:38:53 -0500] [83200] [ERROR] Retrying in 1 second.
10:38:54 PM web.1 | [2017-01-08 22:38:54 -0500] [83200] [ERROR] Connection in use: ('0.0.0.0', 3306)
10:38:54 PM web.1 | [2017-01-08 22:38:54 -0500] [83200] [ERROR] Retrying
in 1 second.
MY PROFILE
web: gunicorn project_name.wsgi.application --log-file -
The gunicorn connects when I stop the mysql server, but I get an exception since the project can not connect to the databases.
--Thank you
You can specify the port for Gunicorn as follows -
gunicorn --bind 127.0.0.1:8000
So basically the complete command would be
gunicorn --bind 127.0.0.1:8000 myproject.wsgi:application
You can change 8000 to any of your desired port number.
To install mod_wsgi on MacOS X see:
https://pypi.python.org/pypi/mod_wsgi
All you need to do is pip install mod_wsgi.
You can then use mod_wsgi-express on the command line to run it on an unprivileged port, with all configuration done for you.
Or, you can integrate it with existing Apache installation and manually configure it yourself by running mod_wsgi-express module-config and taking what it outputs and add it to the main Apache configuration for the system. Then add you specific WSGI application configuration to the Apache configuration file as well.
I have scenario in which i want gunicorn workers to acknowledge and fulfill ongoing requests before supervisord starts after stopping(restart).
Can anyone help me with this.
Set your Supervisor configuration as autostart and autorestart as true.
Then kill the gunicorn by
kill -HUP `cat /tmp/process.pid`
It will shutdown gracefully hence processing all requests and supervisor will restart it according to the configurations.
You can also use reload of gunicorn as it sends HUP signal.
More precisely, you can to reload your app by sending HUP signal by: pkill -HUP gunicorn.
Because the /var/run/ directory is missing this pid:
find /var/run/ -iname '*gunicorn*' | wc -l
0
See the official Gunicorn docs, http://docs.gunicorn.org/en/stable/faq.html
and man 1 pkill
docker stop has a standard timeout of 10s (Reference - Docker Stop). This time window may be to short for the shutdown of mysql or influxdb to reach a consistent state on file system. If I stopped the container by hand, I would shut it down with docker stop -t 60 mysql. But that is not the default case. The containers are on auto restart and started and stopped with the docker daemon.
If I stop the docker daemon (e.g. on system reboot), the daemon will stop all running container with a timeout of 10 seconds, which can cause inconsistent dbs.
Question: Is there a way to set the global timeout for docker stop or the daemon stop?
Update 2016-05-03: Added [Feature Request] Add config parameter to change stop timeout for containers or globally #22471 on github.
https://docs.docker.com/engine/reference/commandline/dockerd/
Use the following config
--shutdown-timeout int Set the default shutdown timeout (default 15)
or put it in docker daemon.json like below and restart docker daemon
tee /etc/docker/daemon.json <<-'EOF'
{
"shutdown-timeout": 30,
"live-restore": true
}
EOF
systemctl restart docker
systemctl status docker
I'm pretty sure there isn't a global setting for this. It would be a nice feature, and you should submit an issue to suggest it, and if you have time submit a pull request to implement.
When I enter the following command:
/etc/init.d/contextBroker start
I get the following output:
Starting contextBroker... cat: /var/run/contextBroker/contextBroker.pid: No such file or directory
pidfile not found [FAILED]
I have two machines where I am practising with context broker and I havent touched the second one in days after I succesfully installed it and managed to receive a post message from a remote weather station.
I see that the directory /var/run/contextBroker/ is actually empty
What should I do to fix this now? reinstal context broker or?
So is this somehow my fault and how do I prevent in the future? I dont want this happening when my app goes live.
EDIT1: the orion version is 0.20.0
EDIT2: I just reinstalled contextBroker and I get the same problem. What are exectly the contents of that directory? Could I maybe just create the files inside?
EDIT3: Since running contextBroker as a system service still yields an unsuccessful start, I also attempted to run it symply by typing:
contextBroker in the command line, after which I get the following response
INFO#14:03:03 contextBroker.cpp[1346]: Orion Context Broker is running
[root#localhost DevF12]# INFO#14:03:03 MongoGlobal.cpp[181]: Successful connection to database
INFO#14:03:03 contextBroker.cpp[1157]: Connected to mongo at localhost:orion
INFO#14:03:03 MongoGlobal.cpp[499]: Database Operation Successful ({ conditions.type: "ONTIMEINTERVAL" })
FATAL#14:03:03 rest.cpp[1013]: Fatal Error (error starting REST interface)
EDIT4: Ok so I tried ps aux | grep contextBroker and the result is:
494 2196 0.0 7.0 688696 135116 ? Ssl Apr21 0:02 /usr/bin/contextBroker -port 1026 -logDir /var/log/contextBroker -pidpath /var/run/contextBroker/contextBroker.pid -dbhost localhost -db orion
root 7299 0.0 6.9 621052 134440 ? Ssl 04:21 0:00 contextBroker -port 1028
root 8870 0.0 0.0 103256 848 pts/0 S+ 08:51 0:00 grep contextBroker
but there simply isnt anything in /var/run/contextBroker/
Should I put contextBroker.pid by myself? and if so, what should the contents be?
EDIT5: I just ran netstat -ntlpd | grep 1026 and the output is:
tcp 0 0 0.0.0.0:1026 0.0.0.0:* LISTEN 2196/contextBroker
tcp 0 0 :::1026 :::* LISTEN 2196/contextBroker
So I guess nothing else but contextBroker is listening?
For the record (it was answered in the comments).
The message FATAL#XX:XX:XX rest.cpp[1013]: Fatal Error (error starting REST interface) means that there is a networking problem. Usually an interface or an already used port.
The usual cause is that there is another instance of Orion running (as a service, for example).
The way to solve it would be to kill the process entirely. Show all Orion processes with ps aux | grep contextBroker and issue a kill -9 <pid>, where <pid> is the process number (the second column of the output of the ps command).