Closed heyimalex closed 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)
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:
/etc/uwsgi/store.ini
(whole thing for posterity)Run
tail -f
onstore.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
. Nowls /var/log/uwsgi/
; onlystore.log
andemperor.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 tostore.log
.Restart uwsgi (my emperor is managed by upstart so
service uwsgi restart
). Now the logs are written tostore2.log
.v2.0.7 via pip on trusty