On Thu, Dec 29, 2011 at 7:45 AM, Roberto De Ioris <[email protected]> wrote:
> > > Hey, > > > > Came up against another curious problem today. > > > > Supervisor seems to not always kill uwsgi correctly, and sometimes can > end > > up with workers still listening on the unix socket. > > > > Although the answer is ultimately to kill the uwsgi processes, this is > not > > something which can always be detected or automated. > > > > Is it possible to force uWSGI to create an exclusive lock on a unix > > socket, > > and if it encounters another uWSGI master instance, it will refuse to > > listen on the socket and die? > > > > I saw 'no-orphans', but this would only work if the master instance was > > dead (which it doesn't appear to be). > > > > Thanks > > > > > > can you paste the supervisor config ? > > Expecially in 1.0 tree if you send the INT/QUIT signal the instance and > its workers will die. I suspect you have set some wrong signal in > supervisor. > [program:ddcms_prod] command=/usr/sbin/chroot /home/chroot /bin/su duke -c "/usr/local/bin/uwsgi --xmlconfig /home/chroot/home/duke/webapps/ddcms.prod/conf/uwsgi.xml" directory=/home/chroot/home/duke/webapps/ddcms.prod/webapp environment=DJANGO_ENVIRONMENT=dev ;user=duke autostart=true autorestart=true stdout_logfile=/home/chroot/home/logs/uwsgi/ddcms.prod/supervisord.stdout.log redirect_stderr=true stopsignal=QUIT Should I change the stopsignal to something else?? > By the way, instead of using locking, a better check would be directly > "pinging" the requested socket, if it respond the instance is still > running. > As the 'ping' function is part of the uwsgi api, i think it should be a > 3-4 line patch. > Thanks! Is there any chance we could have this included in the core, as an XML option? Something like, <exclusive-socket/> maybe?? Take for example, nginx/apache etc, if they can't listen on the appropriate socket/port, they refuse to start up - same principle, but on an opt-in basis so it doesn't become backwards incompatible maybe?? > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
