I'm just testing uWSGI by following the quick-start guide in official web site. But, I am facing a problem.
This is what I did. It's exactly same as the steps in quick guide.
$ uwsgi --http :9090 --wsgi-file foobar.py
*** Starting uWSGI 2.0.19.1 (64bit) on [Sat Mar 12 09:28:41 2022] ***
compiled with version: Clang 11.0.0 on 18 January 2021 21:53:23
os: Darwin-21.3.0 Darwin Kernel Version 21.3.0: Wed Jan 5 21:37:58 PST 2022; root:xnu-8019.80.24~20/RELEASE_X86_64
nodename: mac-brian.local
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 16
current working directory: /Users/brian/Documents/project/uwsgi_test
detected binary path: /opt/anaconda3/envs/price_analysis/bin/uwsgi
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 5568
your memory page size is 4096 bytes
detected max file descriptor number: 256
lock engine: OSX spinlocks
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :9090 fd 4
spawned uWSGI http 1 (pid: 10349)
uwsgi socket 0 bound to TCP address 127.0.0.1:59738 (port auto-assigned) fd 3
Python version: 3.9.1 | packaged by conda-forge | (default, Jan 10 2021, 02:52:42) [Clang 11.0.0 ]
Fatal Python error: init_import_site: Failed to import the site module
Python runtime state: initialized
Traceback (most recent call last):
File "/opt/anaconda3/envs/price_analysis/lib/python3.9/site.py", line 73, in <module>
import os
File "/opt/anaconda3/envs/price_analysis/lib/python3.9/os.py", line 29, in <module>
from _collections_abc import _check_methods
File "/opt/anaconda3/envs/price_analysis/lib/python3.9/_collections_abc.py", line 416, in <module>
class _CallableGenericAlias(GenericAlias):
TypeError: type 'types.GenericAlias' is not an acceptable base type
And this is my foobar.py:
def application(env, start_response):
start_response('200 OK', [('Content-Type','text/html')])
return [b"Hello World"]
After this I tried to connect to the http://localhost:9090 in this way.
curl -v 127.0.0.1:9090
These are the responses.
curl -v 127.0.0.1:9090
* Trying 127.0.0.1:9090...
* Connected to 127.0.0.1 (127.0.0.1) port 9090 (#0)
> GET / HTTP/1.1
> Host: 127.0.0.1:9090
> User-Agent: curl/7.77.0
> Accept: */*
>
[uwsgi-http] unable to connect() to node "127.0.0.1:59738" (0 retries): Connection refused
[uwsgi-http] unable to connect() to node "127.0.0.1:59738" (1 retries): Connection refused
[uwsgi-http] unable to connect() to node "127.0.0.1:59738" (2 retries): Connection refused
[uwsgi-http] unable to connect() to node "127.0.0.1:59738" (3 retries): Connection refused
* Empty reply from server
* Closing connection 0
curl: (52) Empty reply from server
I expected Hello World but I get empty messages from the server.
How can I solve this?
Related
I'm getting duplicate HAProxy log messages from my LUA script and don't understand why.
haproxy.cfg
global
log /dev/log local0 warning
chroot /var/lib/haproxy
stats socket /run/haproxy/admin.sock mode 660 level admin expose-fd listeners
stats timeout 30s
user haproxy
group haproxy
daemon
# Default SSL material locations
ca-base /etc/ssl/certs
crt-base /etc/ssl/private
# See: https://ssl-config.mozilla.org/#server=haproxy&server-version=2.0.3&config=intermediate
ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
lua-load /home/tester/hello.lua
defaults
log global
mode http
option httplog
option dontlognull
timeout connect 5000
timeout client 50000
timeout server 50000
errorfile 400 /etc/haproxy/errors/400.http
errorfile 403 /etc/haproxy/errors/403.http
errorfile 408 /etc/haproxy/errors/408.http
errorfile 500 /etc/haproxy/errors/500.http
errorfile 502 /etc/haproxy/errors/502.http
errorfile 503 /etc/haproxy/errors/503.http
errorfile 504 /etc/haproxy/errors/504.http
frontend test_endpoint
bind *:9202
http-request lua.tester
hello.lua
function tester(txn)
core.log(core.debug, "debug message!\n")
core.log(core.info, "info message!\n")
core.log(core.warning, "warning message!\n")
core.log(core.err, "error message!\n")
end
core.register_action('tester', {'http-req'}, tester)
HAProxy was installed as a package and therefore writes to /var/log/haproxy.log by default on my ubuntu system. This is what I see in the log:
Jan 25 05:47:23 ubuntu haproxy[65622]: warning message!.
Jan 25 05:47:23 ubuntu haproxy[65622]: error message!.
Jan 25 05:47:23 ubuntu haproxy[65615]: [info] 024/054723 (65622) : info message!.
Jan 25 05:47:23 ubuntu haproxy[65615]: [warning] 024/054723 (65622) : warning message!.
Jan 25 05:47:23 ubuntu haproxy[65615]: [err] 024/054723 (65622) : error message!.
I expected only the top 2 lines. Can anyone explain why the other lines appear in the log and how I can configure them out?
Thanks in advance!
for info:
# haproxy -v
HA-Proxy version 2.2.8-1ppa1~bionic 2021/01/14 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2025.
Known bugs: http://www.haproxy.org/bugs/bugs-2.2.8.html
Running on: Linux 4.15.0-134-generic #138-Ubuntu SMP Fri Jan 15 10:52:18 UTC 2021 x86_64
UPDATE:
Looking at the hlua.c source code, I can see the extra 3 lines are stderr - the logging is sent to the log (green box) and also to stderr (red box):
I had to add "-q" flag to ExecStart in /lib/systemd/system/haproxy.service. It now looks like this:
ExecStart=/usr/sbin/haproxy -Ws -f $CONFIG -p $PIDFILE -q $EXTRAOPTS
Note: adding "quiet" to the global section in haproxy.cfg did not work for me. Perhaps broken?
Please do as i do in your vps and then maybe the issue reproduced,replace the variable $vps_ip with your real vps ip during the below steps.
wget https://saimei.ftp.acc.umu.se/debian-cd/current/amd64/iso-cd/debian-10.4.0-amd64-netinst.iso
transmission-create -o debian.torrent debian-10.4.0-amd64-netinst.iso
Create a trackerless torrent ,show info on it:
transmission-show debian.torrent
Name: debian-10.4.0-amd64-netinst.iso
File: debian.torrent
GENERAL
Name: debian-10.4.0-amd64-netinst.iso
Hash: a7fbe3ac2451fc6f29562ff034fe099c998d945e
Created by: Transmission/2.92 (14714)
Created on: Mon Jun 8 00:04:33 2020
Piece Count: 2688
Piece Size: 128.0 KiB
Total Size: 352.3 MB
Privacy: Public torrent
TRACKERS
FILES
debian-10.4.0-amd64-netinst.iso (352.3 MB)
Open the port which transmission running on your vps.
firewall-cmd --zone=public --add-port=51413/tcp --permanent
firewall-cmd --reload
Check it from your local pc.
sudo nmap $vps_ip -p51413
Host is up (0.24s latency).
PORT STATE SERVICE
51413/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 1.74 seconds
Add the torrent and seed it with transmission's default username and password on your vps(with your own if you already change it):
transmission-remote -n "transmission:transmission" --add debian.torrent
localhost:9091/transmission/rpc/ responded: "success"
transmission-remote -n "transmission:transmission" --list
ID Done Have ETA Up Down Ratio Status Name
1 0% None Unknown 0.0 0.0 None Idle debian-10.4.0-amd64-netinst.iso
Sum: None 0.0 0.0
transmission-remote -n "transmission:transmission" -t 1 --start
localhost:9091/transmission/rpc/ responded: "success"
Get the debian.torrent from your vps into local pc.
scp root#$vps_ip:/root/debian.torrent /tmp
Now to try download it in your local pc.
aria2c --enable-dht=true /tmp/debian.torrent
06/08 09:28:04 [NOTICE] Downloading 1 item(s)
06/08 09:28:04 [NOTICE] IPv4 DHT: listening on UDP port 6921
06/08 09:28:04 [NOTICE] IPv4 BitTorrent: listening on TCP port 6956
06/08 09:28:04 [NOTICE] IPv6 BitTorrent: listening on TCP port 6956
*** Download Progress Summary as of Mon Jun 8 09:29:04 2020 ***
===============================================================================
[#a34431 0B/336MiB(0%) CN:0 SD:0 DL:0B]
FILE: /tmp/debian-10.4.0-amd64-netinst.iso
-------------------------------------------------------------------------------
I wait about one hour ,the download progress is always 0%.
If you're using DHT, you have to open a UDP port in your firewall and then, depending on what you're doing, you can specify that port to aria2c. From the docs:
DHT uses UDP. Since aria2 doesn't configure firewalls or routers for port forwarding, it's up to you to do it manually.
$ aria2c --enable-dht --dht-listen-port=6881 file.torrent
See this page for some more examples of using DHT with aria2c.
I've installed a neo4j database on a Google Cloud Compute instance and am wanting to connect to the database from my laptop.
[1] I have neo4j running on Google Cloud
● neo4j.service - Neo4j Graph Database
Loaded: loaded (/lib/systemd/system/neo4j.service; disabled; vendor preset: enabled)
Active: active (running) since Sat 2017-09-30 09:33:39 UTC; 1h 3min ago
Main PID: 2099 (java)
Tasks: 41
Memory: 504.5M
CPU: 18.652s
CGroup: /system.slice/neo4j.service
└─2099 /usr/bin/java -cp /var/lib/neo4j/plugins:/etc/neo4j:/usr/share/neo4j/lib/*:/var/lib/neo4j/plugins/* -server -XX:+UseG1GC -XX:-OmitStackTraceInFastThrow -XX:+AlwaysPreTouch -XX:+U
nlockExperimentalVMOptions -XX:+TrustFinalNonStaticFields -XX:+DisableExplicitGC -Djdk.tls.ephemeralDHKeySize=2048 -Dunsupported.dbms.udc.source=debian -Dfile.encoding=UTF-8 org.neo4j.server.Commu
nityEntryPoint --home-dir=/var/lib/neo4j --config-dir=/etc/neo4j
Sep 30 09:33:40 neo4j-graphdb-server neo4j[2099]: certificates: /var/lib/neo4j/certificates
Sep 30 09:33:40 neo4j-graphdb-server neo4j[2099]: run: /var/run/neo4j
Sep 30 09:33:40 neo4j-graphdb-server neo4j[2099]: Starting Neo4j.
Sep 30 09:33:42 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:33:42.948+0000 INFO ======== Neo4j 3.2.5 ========
Sep 30 09:33:42 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:33:42.988+0000 INFO Starting...
Sep 30 09:33:44 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:33:44.308+0000 INFO Bolt enabled on 127.0.0.1:7687.
Sep 30 09:33:47 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:33:47.043+0000 INFO Started.
Sep 30 09:33:48 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:33:48.160+0000 INFO Remote interface available at http://localhost:7474/
Sep 30 09:39:17 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:39:17.918+0000 WARN badMessage: 400 No URI for HttpChannelOverHttp#27d4a9b{r=0,c=false,a=IDLE,uri=-}
Sep 30 09:46:18 neo4j-graphdb-server neo4j[2099]: 2017-09-30 09:46:18.374+0000 WARN badMessage: 400 for HttpChannelOverHttp#6cbed0ca{r=0,c=false,a=IDLE,uri=-}
[2] I've created a firewall rule on Google Cloud to allow external access to the DB server
The network tag of "google-db-server" has been added to the Google Cloud Compute server.
My expectation is that the rule below will allow any external machine to connect to port 7474 on the Google Cloud Compute instance
user#machine:~/home$ gcloud compute firewall-rules create custom-allow-neo4j --action ALLOW --rules tcp:7474 --description "Enable access to the neo4j database" --direction IN --target-tags google-db-server
user#machine:~/home$ gcloud compute firewall-rules list --format json
[
{
"allowed": [
{
"IPProtocol": "tcp",
"ports": [
"7474"
]
}
],
"creationTimestamp": "2017-09-30T00:25:51.220-07:00",
"description": "Enable access to the neo4j database",
"direction": "INGRESS",
"id": "5767618134171383824",
"kind": "compute#firewall",
"name": "custom-allow-neo4j",
"network": "https://www.googleapis.com/compute/v1/projects/graphdb-experiment/global/networks/default",
"priority": 1000,
"selfLink": "https://www.googleapis.com/compute/v1/projects/graphdb-experiment/global/firewalls/custom-allow-neo4j",
"sourceRanges": [
"0.0.0.0/0"
],
"targetTags": [
"google-db-server"
]
},
[3] Running nmap from the Google Cloud server instance shows that port 7474 is available locally, and I can telnet to that port locally
google_user#google-db-server:~$ nmap -p 22,80,443,7474 localhost
Starting Nmap 7.01 ( https://nmap.org ) at 2017-09-30 10:46 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000081s latency).
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp closed https
7474/tcp open unknown
Nmap done: 1 IP address (1 host up) scanned in 0.03 seconds
google-user#google-db-server:~$ telnet localhost 7474
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
[4] However I am unable to connect from my laptop and nmap shows port 7474 as unavailable
user#machine:~/home$ nmap -p 22,80,443,7474 35.201.26.52
Starting Nmap 7.01 ( https://nmap.org ) at 2017-09-30 20:50 AEST
Nmap scan report for 52.26.201.35.bc.googleusercontent.com (35.201.26.52)
Host is up (0.28s latency).
PORT STATE SERVICE
22/tcp open ssh
80/tcp open http
443/tcp closed https
7474/tcp closed unknown
Nmap done: 1 IP address (1 host up) scanned in 0.75 seconds
So despite the firewall rule being created to allow any IP address to connect to the Google Cloud Compute instance on tcp:7474, I'm still unable to access this port from my laptop.
Am I missing some additional steps?
It looks like neo4j is only listening on the loopback interface. This means it only accepts connections from the same machine. You can verify this by running sudo netstat -lntp. If you see 127.0.0.1:7474, it's only listening on loopback. It should be 0.0.0.0:7474.
you can fix this in the neo4j config by setting dbms.connector.bolt.listen_address to 0.0.0.0:7474. Your Linux distribution may also have a different place to set this configuration.
On my mac I am running Windows Server 2016 in VMware. In there I am running Ubuntu in vagrant/Virtual Box. In there I am trying to run a django app in a docker container with nginx/uwsgi.
uwsgi is failing to start with:
[uWSGI] getting INI configuration from /opt/django/CAPgraph/uwsgi.ini
*** Starting uWSGI 2.0.15 (64bit) on [Thu Aug 17 20:01:23 2017] ***
compiled with version: 6.4.0 20170805 on 17 August 2017 06:10:50
os: Linux-3.13.0-128-generic #177-Ubuntu SMP Tue Aug 8 11:40:23 UTC 2017
nodename: 37db4344b5ae
machine: x86_64
clock source: unix
pcre jit disabled
detected number of CPU cores: 1
current working directory: /
detected binary path: /usr/local/bin/uwsgi
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
chdir() to /opt/django/CAPgraph/
your memory page size is 4096 bytes
detected max file descriptor number: 524288
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
bind(): Operation not permitted [core/socket.c line 230]
In VMware the folder is set for sharing for everyone with write permission. That is mounted in the vagrant VM where it is 777, and in the docker container is it also 777. I can create files in the dir from all 3 places. But it seems uwsgi cannot create the socket.
I tried a short python script as a test from vagrant and that could not create a socket either:
vagrant#vagrant-ubuntu-trusty-64:/vagrant$ python -c "import socket as s; sock = s.socket(s.AF_UNIX); sock.bind('/vagrant/app.sock')"
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/usr/lib/python2.7/socket.py", line 224, in meth
return getattr(self._sock,name)(*args)
socket.error: [Errno 1] Operation not permitted
Anyone know how I can resolve this?
UPDATE: I changed the dir to /tmp where I can create a socket with my python script, but still uwsgi fails with the same error.
UPDATE 2: I created the socket in /tmp with my python script, chmod-ed it to 777 and still I get the same error from uwsgi.
Use any other folder other than /vagrant. I usually use /home/vagrant
The problem is that /vagrant is not same as a normal folder. If you execute the command mount | grep vagrant you will find it uses a vboxfs file system, which for some reason doesn't gel well with docker
I feel so dumb admitting this, but I am struggling on the uWSGI tutorial for Django here
My problem is after making a test.py file as described in the tutorial, and running the command:
uwsgi --http :8000 --wsgi-file test.py
I go to port :8000 on the IP adress for my VPS and the connection times out. I have been playing around with nginx and have been able to get the "Welcome to nginx" screen to successfully show itself. The output on my terminal after starting uwsgi with the above command is:
--wsgi-file test.py
*** Starting uWSGI 1.9.17.1 (64bit) on [Thu Oct 10 20:58:40 2013] ***
compiled with version: 4.6.3 on 10 October 2013 20:17:02
os: Linux-3.9.3-x86_64-linode33 #1 SMP Mon May 20 10:22:57 EDT 2013
nodename: Name
machine: x86_64
clock source: unix
detected number of CPU cores: 8
current working directory: /usr/local/uwsgi-tutorail/mytest
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
uWSGI running as root, you can use --uid/--gid/--chroot options
*** WARNING: you are running uWSGI as root !!! (use the --uid flag) ***
*** WARNING: you are running uWSGI without its master process manager ***
your processes number limit is 7883
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uWSGI http bound on :8000 fd 4
spawned uWSGI http 1 (pid: 18638)
uwsgi socket 0 bound to TCP address 127.0.0.1:52306 (port auto-assigned) fd 3
Python version: 2.7.3 (default, Sep 26 2013, 20:13:52) [GCC 4.6.3]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x26599f0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 72792 bytes (71 KB) for 1 cores
*** Operational MODE: single process ***
WSGI app 0 (mountpoint='') ready in 0 seconds on interpreter 0x26599f0 pid: 18637 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI worker 1 (and the only) (pid: 18637, cores: 1)
I am a complete newb at uwsgi, any help would be greatly appreciated.
Not an elegant solution but I was able to "fix" the problem by rebuilding my VPS and starting from scratch.