no python application found, check your startup logs for errors

Geeks, please accept the hero post of 2021 Microsoft x Intel hacking contest>>>

Recently, when building the server, the version of centos6.5, was testing whether the installation of uwsgi was correct, there was a problem, such as the problem

Among them, I checked on the Internet. There are many schemes. I have tried most of them, but the results are not acceptable

When an error similar to “mon Mar 23 10:26:49 2015 – – no Python application found, check your startup logs for errors” is reported in the log, you need to check the XML file carefully
there can be no spaces at the end of the line in this file, and there can be no spaces around the parameters. This problem has been troubling me all night in a virtual environment, you need to configure to the directory where uwsgi is located (in a non virtual environment, you only need to configure to the path where the project is located)
1
2
3
4
seeing this, I think the problem should be as mentioned above, It should be out of the configuration file:

#Yaml format
uwsgi:
http: 0.0.0:80
chdir:/Project_ name_ Path
module: project. WSGI
processes: 4
Listen: 100
daemonize:/TMP/uwsgi. Log
pidfile:/TMP/uwsgi. PID
Master: true
disable logging: true
Stats:/TMP/uwsgi. Socket
enable threads: true
buffer size: 32768
1
2
3
4
5
6
7
8
9
10
11
13
14
My configuration file, I use the cursor to walk again, really did not feel the problem of space. But according to the error information (such as the question), I can judge that it should be the problem of chdir and module in the configuration file, but I went to the server to confirm again that there is no problem with this path and the path of the project

First of all, I found that this problem is as follows:
1. I started uwsgi on the server according to the configuration file of uwsgi, and there was no error message. Then I PS aux | grep uwsgi, and I didn’t see the process of uwsgi. Aware of the problem
2. Then I check the log of uwsgi/TMP/uwsgi. Log
3. Tail – F/TMP/uwsgi. Log to dynamically check the log, and find that if the title reports an error

However, I only looked at half of the screen log, but I didn’t look up the log. Later, I happened to think of the last time I had a problem, because I only looked at half of the error messages and missed the key tips. So I decisively turned up the log, did not expect, really found the problem

I see that when I start uwsgi marked in the log, I call python2.6.6, the default version of the system. But I’m using the version of Python 2.7.9. I’ve upgraded it. Why do I still use the old version of Python

Look at the system variables
I looked at the system environment variable path, in which there is/usr/lib64/bin path (python2.6.6), but there is no/usr/local/bin path (python2.7.9), so

Go to/etc/profile, add export path =/usr/local/bin: $path, log out, log in again, and then start uwsgi
looking back, let’s see why the headline is wrong?Because I actually installed python2.7.9 on the basis of python2.6.6, I just made a soft connection, and did not add the environment variables of python2.7.9 to the system environment variables. The environment and third-party packages of my project were all installed under python2.7.9. When starting uwsgi, I found the location of the project according to the configuration information chdir and module of uwsgi, However, when loading the code, there are a lot of import errors due to the inability to find the third-party library (turning up the log, it’s easy to ignore the error if it can’t be displayed on one screen). Therefore, the configuration file module of uwsgi doesn’t work, and the result is no Python application found. It’s not uncommon to report this error

Another problem: when I change HTTP in the configuration file of uwsgi to socket, the service of uwsgi can be started, but there is no service, so the browser can’t access itCopyright notice: This article is the original article of the blogger, please attach the blog link if you reprint it

Similar Posts: