unbit / uwsgi

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

logto not updated on vassal reload #739

Closed heyimalex closed 10 years ago

heyimalex commented 10 years ago

I have a python application managed by the emperor. Changes to the ini file trigger reloads vassals appropriately, but changes to the logto option won't actually change where uwsgi logs to unless I restart the emperor process.

emperor command:

uwsgi --emperor /etc/uwsgi --logto /var/log/uwsgi/emperor.log

/etc/uwsgi/store.ini (whole thing for posterity)

[uwsgi]
socket = /tmp/store.sock
chmod-socket = 664
uid = www-data
gid = www-data
chdir = /var/www/store/
wsgi-file = /var/www/store/app.py
callable = app
processes = 16
close-on-exec = true
logto = /var/log/uwsgi/store.log

Run tail -f on store.log and it looks like the vassals are spawning, requests are coming in, everything is going smoothly.

Open a new term and change logto in the ini to store2.log. Now ls /var/log/uwsgi/; only store.log and emperor.log show up. Check the tail in the other term and it appears that the emperor picked up the change and is reloading the vassals, but continues to log to store.log.

Restart uwsgi (my emperor is managed by upstart so service uwsgi restart). Now the logs are written to store2.log.

v2.0.7 via pip on trusty

unbit commented 10 years ago

Logging system is mapped to fds 1 and 2 and (by default) they are inherited between reloads. You can add log-reopen option to force reopening the log system at every reload, but expect some inconsistence (like some message log being swallowed during startup). Safest approach is stopping and restarting the vassal (no need to reload the whole Emperor)