RE: Supervising FastCGI Listeners

More details about the issue, I replicated it on a fresh FreeBSD
install and another later version of debian (Sid).  some output that
might be interesting:

bougyman@picasso:~/service$ runsvstat -l [1-9] 10 
1: run (pid 23309) 50 seconds
  log: run (pid 23316) 49 seconds
2: run (pid 30035) 8567 seconds
  log: run (pid 30031) 8568 seconds
3: run (pid 30521) 8420 seconds
  log: run (pid 30515) 8421 seconds
4: run (pid 30522) 8420 seconds
  log: run (pid 30516) 8421 seconds
5: run (pid 30535) 8419 seconds
  log: run (pid 30530) 8420 seconds
6: run (pid 30545) 8418 seconds
  log: run (pid 30540) 8419 seconds
7: run (pid 30558) 8416 seconds
  log: run (pid 30553) 8417 seconds
8: run (pid 30568) 8415 seconds
  log: run (pid 30563) 8416 seconds
9: run (pid 30578) 8414 seconds
  log: run (pid 30573) 8415 seconds
10: run (pid 30590) 8412 seconds
  log: run (pid 30586) 8413 seconds
bougyman@picasso:~/service$ ps aux|egrep 'bougy.*ruby1.8'
bougyman 30038  0.0  0.4 28672 17632 ?       S    19:06   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30526  0.0  0.4 19976 17116 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30528  0.0  0.3 15864 13048 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30538  0.0  0.3 15864 13052 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30548  0.0  0.4 28672 17632 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30561  0.0  0.4 28652 17620 ?       S    19:08   0:01
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30571  0.0  0.4 19976 17116 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30581  0.0  0.4 19976 17120 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 30593  0.0  0.4 19976 17120 ?       S    19:08   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 23312  0.9  0.3 15744 12876 ?       S    21:28   0:00
/usr/bin/ruby1.8
/home/bougyman/websites/bougyman.com/public/dispatch.fcgi

Notice how none of the pids in the supervisor match the PID of any of
the fastcgi listeners?  I'm assuming this is because of a fork of some
sort, but the end result becomes this: (from ps awwfux):

                                                                      
      \_ runsvdir /home/bougyman/service
bougyman 16557  0.0  0.0    24   24 ?        S    17:57   0:00        
 \_ runsv 1
bougyman 23309  0.0  0.0  1352  260 ?        S    21:28   0:00        
 |   \_ fghack cgi-fcgi -start -connect 172.30.100.10:19
71 /home/bougyman/websites/bougyman.com/public/dispatch.fcgi
bougyman 23311  0.0  0.0     0    0 ?        Z    21:28   0:00        
 |   |   \_ [cgi-fcgi] <defunct>


So I have one zombied process for every running processes.  If I send
a TERM to the supervisor it stop, but the /usr/bin/ruby1.8 process
stays alive holding that port so it cannot be restarted.  I have to
send the dispatch.fcgi PID a TERM directly to stop it.  Is there any
workaround for this so a TERM to the supervisor will pass through to
the fastcgi listener?  I'm wondering why the fcgi listeners won't
recognize the supervisor as their parents at all.  Inquiring minds
wanna know.
TJ
-- 
bougyman
___________________________________
fastcgi-developers mailing list
http://fastcgi.com/fastcgi-developers/