[SOLVED] Cherrypy - no response to requests

[kryszen2]

Hello.
I have problem with deploying cherrypy on Centos7.
I've worked with cherrypy on Windows (json, postgresql etc.) for few years now without any problems and I don't uderstand what I do wrong in case of Centos.

My "obervations" so far:
- Cherrypy is installed as Python3 package
- There is no any issues with Python3 scripts
- SSH, sFTP work without any issues
- Apache operates on ports like 80, 6060, 9090 without any issues
- iptables and firewalld turned off
- no other software is listening to port 2020
- cherrypy starts without syntax error notifications
- no cherrypy processes duplicated
- 'localhost' and '127.0.0.1' are resolved properly



Sample cherrypy script:

Code: Select all

import cherrypy

class HelloWorld(object):
    @cherrypy.expose
    def index(self):
        return "Hello World!"

cherrypy.config.update({'Access-Control-Allow-Origin': 'http://127.0.0.1',
    'server.socket_host': '127.0.0.1', 'server.socket_port': 2020})

cherrypy.quickstart(HelloWorld())

The problem is that I can't receive any response to a request.


command:
netstat -tulpn | grep :2020
output:
LISTEN 5239/python3 (PID is correct - this is process started by cherrypy)



command:
wget http://127.0.0.1:2020
output:
Connecting to 127.0.0.1:2020... connected.
HTTP request sent, awaiting response...


- the same effect if I use Python3 'requests' module (no response from cherrypy)
- unfortunately cherrypy wasn't able to write down any logs during requests

Could somebody with more experience with centos please point me in the right direction, because I have no idea where to go next / what to check.

Regards.

[aks]

Don't know.

But if you login to the CentOS box as root and type:

setenforce Permissive

at the # prompt and then execute you Python thing as you normally do, does it work?

[kryszen2]

Thank you for your answer.

I also thought about SELinux.

Unfortunately my SELinux is disabled - cherrypy isn't blocked by this security feature.

[kryszen2]

I also tried with built-in python http server:

1.
I killed cherrypy process

2.
command:
python3 -m http.server 2020 --bind 127.0.0.1
output:
Serving HTTP on 127.0.0.1 port 2020 (http://127.0.0.1:2020/) ...

3.
command:
ps aux
output:
13487 0.1 0.4 91588 14432 pts/0 T 08:44 0:00 python3 -m http.server 2020 --bind 127.0.0.1

4.
command:
netstat -tulpn | grep :2020
output:
tcp 1 0 127.0.0.1:2020 0.0.0.0:* LISTEN 13487/python3

5.
command:
wget http://127.0.0.1:2020
output:
Connecting to 127.0.0.1:2020... connected.
HTTP request sent, awaiting response...


The same answer as with cherrypy. What does it mean?

[aks]

I guess it means:

1. The socket is up and the daemon is running.
2. There's nothing there to pass out (in terms of actual content) or whatever does the content is not doing the content - i.e.: the engine.

If you have (say) an index.html, you could just telnet (or use any line protocol tool) to 127.0.0.1 on port 2020 and type:

GET /index.html HTTP/1.1
host: <insert hostname here>

(and then hit enter a couple of times). If you do not get the content of /index.html, then the problems lies in either the actual HTTP "engine" or the index.html is rubbish.

curl -v is quite good too (shows you actual headers for example).

[kryszen2]

Thank you. You pointed me in the right direction. You were right: there was nothing there to pass out.

It found out that the problem was that cherrypy server wasn’t active at all, because of the wrong initiation method. It should be started in background and not as usual Python script (otherwise it stops working every time system administrator goes back to prompt shell).
So in fact cherrypy server wasn’t working even though its process was visible and it was operating on the right port.



Here is the solution:


instead of this command:

python3 cherrypy_script.py

should be this one:

nohub python3 cherrypy_script.py &