We use supervisor with gunicorn with stopsignal=INT successfully -- might be worth a try.
- Dan On Feb 21, 2013, at 1:09 PM, "David Birdsong" <david.birds...@gmail.com> wrote: > if gunicorn is doing it's own forking, which i'm guessing it does, > then supervisord won't know about the child processes. > > i've not used gunicorn, but when i run tornado servers, i dont use > tornado's process manager, i instead use supervisord's argument > templating and numprocs to fork direct children from supervisord. the > arg templating empowers you to pass in different ports to each > process. > > so instead you'd run two gunicorn processes directly from supervisord > on different ports. > > > (aside, are you using gunicorn to run graphite instead of django?) > > On Thu, Feb 21, 2013 at 9:54 AM, John Wong <gokoproj...@gmail.com> wrote: >> Hi, >> >> I bumped into this biazzard problem today. I never had any issue with >> supervisord for the last two weeks since I started using it. >> >> (gcs)giabadmin@giab-master:/opt/graphyte/gcs/tests/integration$ ps -elf|grep >> "gcs" >> 4 S 1011 3654 2899 1 80 0 - 3811 poll_s 17:48 ? 00:00:01 >> /opt/graphyte/vens/gcs/bin/python /opt/graphyte/vens/gcs/bin/gunicorn_paster >> /opt/graphyte/gcs/development.ini -w 1 -t 3600 >> 1 S 1011 3659 3654 8 80 0 - 11852 ep_pol 17:48 ? 00:00:11 >> /opt/graphyte/vens/gcs/bin/python /opt/graphyte/vens/gcs/bin/gunicorn_paster >> /opt/graphyte/gcs/development.ini -w 1 -t 3600 >> 1 S postgres 3674 1347 0 80 0 - 13192 sk_wai 17:48 ? 00:00:00 >> postgres: postgres gcs 127.0.0.1(47334) idle >> 1 S postgres 3732 1347 0 80 0 - 13001 sk_wai 17:49 ? 00:00:00 >> postgres: postgres gcs 127.0.0.1(47419) idle >> 0 R 1011 3747 1105 3 80 0 - 1157 - 17:50 pts/0 00:00:00 >> grep --color=auto gcs >> >> >> We are looking at GCS. We have two of these. >> >> Then I ran super which is a shortcut for sudo supervisrdctl (I made this >> into a bash alias) >> >> (gcs)giabadmin@giab-master:/opt/graphyte/gcs/tests/integration$ super stop >> gcs >> gcs: stopped >> >> I waited maybe a minute and I saw >> >> (gcs)giabadmin@giab-master:/opt/graphyte/gcs/tests/integration$ ps -elf|grep >> "gcs" >> 1 S 1011 3659 1 4 80 0 - 11852 ep_pol 17:48 ? 00:00:11 >> /opt/graphyte/vens/gcs/bin/python /opt/graphyte/vens/gcs/bin/gunicorn_paster >> /opt/graphyte/gcs/development.ini -w 1 -t 3600 >> 1 S postgres 3674 1347 0 80 0 - 13192 sk_wai 17:48 ? 00:00:00 >> postgres: postgres gcs 127.0.0.1(47334) idle >> 1 S postgres 3732 1347 0 80 0 - 13001 sk_wai 17:49 ? 00:00:00 >> postgres: postgres gcs 127.0.0.1(47419) idle >> 0 R 1011 3784 1105 0 80 0 - 1157 - 17:51 pts/0 00:00:00 >> grep --color=auto gcs >> >> Odd. Still alive. 3659 is still alive. >> >> I can't start my app until I manually kills 3659. Do we know what's causing >> the trouble? >> >> This is my conf: >> >> [program:gcs] >> command=/opt/graphyte/vens/gcs/bin/gunicorn_paster >> /opt/graphyte/gcs/development.ini -w 1 -t 3600 >> user=giabadmin >> autostart=true >> autorestart=false >> stopsignal=QUIT >> log_stdout=true >> log_stderr=true >> logfile=/var/log/graphyte/gcs2/supervisord.log >> stdout_logfile=/var/log/graphyte/gcs2/stdout.log >> stderr_logfile=/var/log/graphyte/gcs2/stderr.log >> logfile_maxbytes=20MB >> logfile_backups=10 >> >> Thanks and sorry for the long post. >> >> Cheers, >> John >> >> _______________________________________________ >> Supervisor-users mailing list >> Supervisor-users@lists.supervisord.org >> https://lists.supervisord.org/mailman/listinfo/supervisor-users > _______________________________________________ > Supervisor-users mailing list > Supervisor-users@lists.supervisord.org > https://lists.supervisord.org/mailman/listinfo/supervisor-users _______________________________________________ Supervisor-users mailing list Supervisor-users@lists.supervisord.org https://lists.supervisord.org/mailman/listinfo/supervisor-users
