uwsgi --stats show different port number for socket - uwsgi

I start uwsgi with the following command:
$ uwsgi --http :8001 --module greendrinks.wsgi --master --stats :9191
If I check out localhost:9191 I see a lot of information. The only port number I see anywhere is in the following snippet:
"sockets":[
{
"name":"127.0.0.1:43864",
"proto":"uwsgi",
"queue":0,
"max_queue":100,
"shared":0,
"can_offload":0
}
],
I was expecting it to say port 8001, but instead I see 43864. Could someone explain how this works?

When you start uWSGI with --http you are starting a http proxy that forward requests to the real instance. The stats you get are from the real instance, that is bound to a random port (the one you see in stats) where the http router/proxy forward requests. You can have a stats server even for the http router/proxy using --http-stats-server. Using --http-socket (instead of --http) instruct the uWSGI instance to directly speak http

Related

docker: Error response from daemon: Ports are not available: listen tcp 0.0.0.0:80: bind:

I'm trying to run a docker image on my windows 10 pro workstation, and I'm getting this error:
docker: Error response from daemon: Ports are not available: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
I'm running this command:
docker run -d -p 80:80 docker/getting-started
And getting this response back:
Unable to find image 'docker/getting-started:latest' locally
latest: Pulling from docker/getting-started
188c0c94c7c5: Pull complete
617561f33ec6: Pull complete
7d856acdaa9c: Pull complete
a0d3c6e28e6d: Pull complete
af69a9b963c8: Pull complete
0739f3815ad8: Pull complete
7c7b75d0baf8: Pull complete
Digest: sha256:b821569034e3b5fae03b40e64a866017067f3bf17effe185b782bdbf02179528
Status: Downloaded newer image for docker/getting-started:latest
7907f6de2b55cc2d66b5ed3a642ac1a97e5bb5ecda5fcf76ff60d7236e8fd32d
docker: Error response from daemon: Ports are not available: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
How can I run a Docker container and get past this problem?
The commands that helped me were:
net stop winnat
net start winnat
Taken from here.
Check if somthing is listening on port 80 by running PowerShell command:
Get-Process -Id (Get-NetTCPConnection -LocalPort 80).OwningProcess
If the response is something like this:
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
0 0.20 4.87 0.00 4 0 System
Then the it is taken.
terminate the process or simply change the port
docker run -d -p 81:81 docker/getting-started 5a0b1202f48ef63c06d75c2f26be2a05f29aa84fe2fbdc5b66f989aa86df98f
docker: Error response from daemon: Ports are not available: listen tcp 0.0.0.0:80: bind: An attempt was made to access a socket in a way forbidden by its access permissions.
I was also using Docker's Getting Started tutorial, ran
docker run -d -p 80:80 docker/getting-started, and got the same error.
I thought that Internet Information Services (IIS) might be using port 80 already. I verified this hunch by going to
Start > IIS > computer name > Sites > Default Web Site > highlight Default Web Site
In the right pane, I saw
Browse *.80 (http)
Yep, port 80 was already in use!
Note: To verify if any process is using port 80, run the command
Get-Process -Id (Get-NetTCPConnection -LocalPort 80).OwningProcess
and look for something like
NPM(K) PM(M) WS(M) CPU(s) Id SI ProcessName
------ ----- ----- ------ -- -- -----------
0 0.20 2.96 0.00 4 0 System
per #Tim Dunphy's answer.
Solution #1
Stop the Default Web site.
Either go to IIS per above > right pane > Manage Website > Stop or
Use the net stop http command, and stop services using the port.
Solution #2
You may not want to stop IIS or any other service running on port 80, so just change the local port! For example,
docker run -d -p 81:80 docker/getting-started
will likely do the trick, as long as you don't have services using port 81.
When I encountered this error there was nothing actively listening on the port.However, the following command showed the port had been reserved by something else
netsh interface ipv4 show excludedportrange protocol=tcp
See This article for more details. A reboot fixed the issue for me.
Most times, Windows IIS (Internet Information Service) or some other program may be using port 80, which is the default http port used by Laravel, Apache and other PHP development environments.
To resolve this issue, Open a new PowerShell window as administrator and simply run this command:
net stop http
A prompt listing all services using the http port is shown and you are given the option of stopping them. enter 'Y' and press Enter. All the services are stopped and port 80 is now free for whatever you want to use it for.
Very useful for testing multiple application environments locally on Windows without having to worry about port configuration.
in my case,the task manager show that a system process is occupy port 80.
when i dive deeper, i found a svchost.exe related to port 80, and it is based on world wide web service
so,just open service list and stop the world wide web service,then everything will be ok,the name of service maybe different, but should include keywords :world wide web
just do it
netsh http add iplisten ipaddress=::
(This has to be run in a command prompt with elevated rights!)

Memcached in standalone Docker container time out and port error

I'm running a setup of 3 Ubuntu virtual machines. Two running the Python production code base and the other has a Memcached Docker container. On the Memcached machine I ran docker run -dit --name production-memcached --publish 11211:11211 memcached:latest.
The code base gets the following error message when trying to interact with it:
"exception": "TimeoutError(10060, 'A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond', None, 10060, None)"
I have ran docker exec -it production-memcached memcached stats and get the error message below.
failed to listen on TCP port 11211: Address already in use
However I've ran netstat -plnt and get tcp6 0 0 :::11211 :::* LISTEN 35030/docker-proxy, which looks fine to me.
I was able to get this to work by opening port 80 and using iptables to forward incoming port 80 to port 11211 but would prefer to use the Memcached port number.
The Memcached client is created by the following line:
client = base.Client(("domain.co.uk", 11211))
Any help would be appreciated, thanks.
DigitalOcean doesn't allow in-traffic on port 11211 to its virtual machines. If you want a Memcached machine you'll also need a virtual machine to act a proxy between you and it. I hope this saves someone the headache it caused me!

How to change Freeradius3 default port(auth1812 & Account1813)

I am using freeradius3.0.4. I need to change the default port(1812,1813) to 18120 and 18130. I don't know where it is. Please help! there is no port setting in the main conf.
Change the port under /etc/service.
This is what I get on freeRADIUS Version 3.0.16:
$ sudo freeradius -X -i 0.0.0.0 -p 1850
radiusd: #### Opening IP addresses and Ports ####
Listening on auth address * port 1850
Listening on acct address * port 1851
Listening on proxy address * port 56033
Ready to process requests
From man freeradius:
-p port
Defines which port is used for receiving authentication packets. Accounting packets are received on "port + 1".
When this command-line option is given, all "listen" sections in radiusd.conf are ignored.
This option MUST be used in conjunction with "-i".
So if you'd like to make the changes permanent, it seems that you need to add a "listen" section to your configuration file with the appropriate parameters (didn't have time to look up the exact syntax).
Also note the constraint that the accounting port is always going to be the authentication port plus one. If you really must modify this behavior on freeRADIUS you might have to change the source code and build your own version.
The port number is defined in /etc/freeradius/3.0/sites-enabled/default:
server default {
listen {
type = auth
ipaddr = *
port = 0
limit {
max_connections = 16
lifetime = 0
idle_timeout = 30
}
}
listen {
ipaddr = *
port = 0
type = acct
limit {
}
}
... more configuration
}
As you can see the configured port is 0. This just means it'll use the FreeRADIUS default port which is 1812/1813 (auth/acct).
If you want to change these port numbers, change them in the above file and run systemctl restart freeradius
If you want to run 2 RADIUS sessions in parallel you'd have to cp -rp /etc/freeradius /etc/freeradius2 and start a second RADIUS process with freeradius -X -d /etc/freeradius2
Hope I could help, I also had this issue
Edits:
0 means that it will use the port defined in /etc/services (by default is 1812)
Instead of freeradius -X -c ... use freeradius -X -d ... to use a custom directory
Use cp -rp ... because otherwise the permissions would change and FreeRADIUS wouldn't work anymore

Putting a uWSGI fast router in front of uWSGI servers running in docker containers

I have multiple Flask based webapps running in docker containers (their processes need to be isolated from the host OS). To run these apps I use uWSGI servers inside the containers. Incoming requests should hit a uWSGI FastRouter with a subscription server (as described here: http://uwsgi-docs.readthedocs.org/en/latest/SubscriptionServer.html). When starting a container, the uWSGI should announce itself based on some internal configuration as a subdomain.
So the setup looks like this:
Request ---> FastRouter ----> container | myapp1 |
|
----> container | myapp2 |
I'm trying to test this on a single host running both the fast router as well as some docker containers.
The FastRouter is started using
uwsgi --fastrouter :1717 --fastrouter-subscription-server localhost:2626 --fastrouter-subscription-slot 1000
Question 1 Do I need to do anything else to get the subscription server running? Is this started together with the fastrouter process?
The containers have two ports mapped from the host to the container: 5000 (the webapp) and 2626 (to subscribe to the fast router).
So they're started like this:
docker run -d -p 5000:5000 -p 2626:2626 myImage $PATH_TO_START/start.sh
Where in start.sh the uWSGI is started as
uwsgi --http :5000 -M --subscribe-to 127.0.0.1:2626:/test --module server --callable env --enable-threads
The output looks good, it prints at the end:
spawned uWSGI master process (pid: 58)
spawned uWSGI worker 1 (pid: 73, cores: 1)
spawned uWSGI http 1 (pid: 74)
subscribing to 127.0.0.1:2626:/test
On the host I can do
curl localhost:5001
And I see the Webserver greeting me from inside the container. However, doing
curl localhost:1717/test
gets no response.
Question 2
Am I getting anything fundamentally wrong here? Should I test differently?
Question 3
How can I debug the FastRouter?
Edit:
Still struggling with this setup. I'm using a separate VPS now for the fastrouter. It is started using
uwsgi --uid fastrouter --master --fastrouter :80 --fastrouter-subscription-server :2626 --daemonize uwsgi.log --pidfile ./uwsgi.pid --chmod-socket --chown-socket fastrouter
WARNING: Think before copying above call for your project since it opens up the subscription service publicly - my plan is to secure it afterwards using the key signing facilities provided by uwsgi since the VPS doesn't have a private network available.
netstat -anp shows
tcp 0 0 0.0.0.0:80 0.0.0.0:* LISTEN 843/uwsgi
udp 0 0 0.0.0.0:2626 0.0.0.0:* 843/uwsgi
unix 3 [ ] STREAM CONNECTED 9089 843/uwsgi
unix 3 [ ] STREAM CONNECTED 9090 843/uwsgi
unix 3 [ ] SEQPACKET CONNECTED 8764 843/uwsgi
unix 3 [ ] SEQPACKET CONNECTED 8763 843/uwsgi
Anyway, using uwsgi nodes with --http :5000 --module server --callable env --enable-threads --subscribe-to [Subscription-Server-IP-Address]2626:/test --socket-timeout 120 --listen 128 --buffer-size 32768 --honour-stdin still leads to the same result - uwsgi logs 'subscribing to', but http://[Subscription-Server-IP-Address]/test is not reachable. Is this kind of routing even possible? Every example I can find only assigns subdomains like [mysub].example.com, root domains, or root domains with some port number. This page includes a hint that the subscription server should be part of a routable address: http://projects.unbit.it/uwsgi/wiki/Example.
So I have a follow-up question:
Is the FastRouter even meant to let nodes announce new routes that haven't yet been set statically in a DNS zone file? I don't really care whether it's http://[key].example.com or http://example.com/[key], what's important is that these keys can be generated from inside a Docker container at setup time of the uwsgi server.
Generally the "dockered" apps run in a different network namespace, so loopback of a docker app is not the same of the fastrouter.
Use unix sockets for subscriptions, they are a great way for inter-namespace communication.
Your commands are good, the fastrouter is pretty verbose so if you do not see messages in its logs it is not working (and eventually you can strace it)

UDP auto-discovery for peers on the same machine

I'm looking at ZeroMQ Realtime Exchange Protocol (ZRE) as inspiration for building an auto-discovery of peers in a distributed application.
I've built a simple prototype application using UDP in Python following this model. It seems it has the (obivious, in retrospect) limitation that it only works for detecting peers if all peers are on other machines. This due to the socket bind operation on the discovery port.
Reading up on SO_REUSEADDR and SO_REUSEPORT tells me that I can't exactly do this with the UDP broadcast scheme as described in ZRE.
If you needed to build an auto-discovery mechanism for distributed applications such that multiple application instances (possibly with different versioN) can run on the same machine, how would you build it?
You should be able to bind each server instance to a different address. The entire subnet 127.0.0.0/8 should resolve to your localhost, so you can set up - for example - one service listening on 127.0.0.1, another listening on 127.0.0.2, etc. Anything from 127.0.0.1 to 127.255.255.254.
# works as expected
nc -l 127.0.0.100 3000 &
nc -l 127.0.0.101 3000 &
# shows error "nc: Address already in use"
nc -l 127.0.0.1 3000 &
nc -l 127.0.0.1 3000 &

Resources