unbit / uwsgi

uWSGI application server container
http://projects.unbit.it/uwsgi
Other
3.45k stars 691 forks source link

uwsgi refuses to start when logto is defined #1555

Closed kakulukia closed 5 years ago

kakulukia commented 7 years ago

its totally weird, but uwsgi refuses to start as soon as i add the logto parameter. Im starting it the following way: uwsgi --ini ../etc/uwsgi.ini

But i only get this one line [uWSGI] getting INI configuration from ../etc/uwsgi.ini

The defined loggin file is readable and writable be the user defined in the ini file, but even when executed with root user uwsgi refuses to start or tell me any hints about this startup problem.

Any idea what might be the problem or how to get uwsgi to tell me anything about why its refusing to start after parsing the ini file?

The rest of the config: (it works without the logging)

[uwsgi]
chdir = /var/www/apps/vfk_portal/project
module = core.wsgi
home = /var/www/apps/vfk_portal/project/.venv
master = true
processes = 10
socket = /var/www/apps/vfk_portal/socket/portal.sock
vacuum = true
env = DJANGO_SETTINGS_MODULE=settings.stage
max-requests = 5000 # respawn processes after serving 5000 requests
chmod-socket = 777
uid = portal
harakiri = 150 
logto = /var/www/apps/vfk_portal/log/uwsgi.log
#logto2 = /var/www/apps/vfk_portal/log/uwsgi-error.log
xrmx commented 7 years ago

Maybe it started and is writing to the logfile?

kakulukia commented 7 years ago

No, it does not start .. its hanging somewhere probably related to the log files. But with this even happening when started as root, i dont have any clue as to why its happening. Normal start produces like 30+ log lines.

And with the logto config its just this one line. Without any error that i could try to fix or google a solution. Is there a more verbose mode of starting uwsgi, that might reveal what wrong?

SamusAranX commented 5 years ago

Did you eventually solve this problem? Over a year later, this problem still exists.

kakulukia commented 5 years ago

im not sure anymore, which project that bug belonged to, but it was not bothering me lately

manskx commented 5 years ago

Same here

kakulukia commented 5 years ago

i think you can spare the "--ini" part and it kinda worked .. btw im using the yml format now ..

kakulukia commented 5 years ago

Shall i reopen the ticket for somebody else to have a look?

Ray57468260 commented 5 years ago

Same problem happens to me and find it actually started; all the startuplog is written into the file that only a row stating initializing showed.

kakulukia commented 5 years ago

Most of problems are caused by either permission problems or a non matching python version of the used uwsgi instance and the projects virtualenv thats supposed to load. Check those two things and i bet you will solve your issue.

wesleytao commented 4 years ago

Exactly the same! service started and systemctl said failed because uwsgi is hanging there.

Same problem happens to me and find it actually started; all the startuplog is written into the file that only a row stating initializing showed.

kakulukia commented 4 years ago

Just a short update: A while ago also because of the above errors i started to not use a system version of uwsgi or any kind of emperor setup. I now have a startup script running the projects server and have that run with pm2 which saves me from incompatibility problems and also gives me better logging and stats about the running process than what i had before. Im happy with this setup.

denisvitez commented 2 years ago

I just had a similar issue after I updated packages and Python version on my embedded device. uWSGI would just get stuck at the first log line: uWSGI] getting INI configuration from No error whatsoever was produced. So I just went line by line in my .ini file until I found the culprit.

Sadly I don't have the information what uwsgi version was used before.

Old versions:

Current versions:

I had to remove the following lines from my .ini file:

req-logger = file:/var/log/uwsgi/app/myapp-req.log
logger = file:/var/log/uwsgi/app/myapp-err.log

After that the uwsgi would proceed and start the application.