On Sat, 8 Mar 2003, Brian Candler wrote:

> > http://groups.google.com/groups?q=ahoward+mod_fcgi+group:comp.lang.ruby&hl=en&lr=&ie=UTF-8&selm=Pine.LNX.4.33.0302121430040.10747-100000%40eli.fsl.noaa.gov&rnum=1
>
> Yes, I found this sufficiently interesting that I kept a copy when you first
> posted it, so thanks for reminding me! It's [ruby-talk:64468] for a shorter
> link.

do you use the http://blade.nagaokaut.ac.jp/ruby/ruby-talk/index.shtml
interface to ruby-talk?  i tried using that search facility to pull up my post
(searching for 'ahoward'), but didn't have any luck??

> Did you find that installing a SIGPIPE handler was actually necessary?
> According to the mod_fastcgi documentation, mod_fastcgi itself sets this for
> applications which it spawns; also libfcgi installs an empty signal handler
> for SIGPIPE as well (OS_SigpipeHandler in libfcgi/os_unix.c)

yeah, i knew about the supposed mod_fastcgi installed PIPE handler but figured
it couldn't hurt.  let me know if find otherwise.  regarding
libfcgi/os_unix.c, this is not used if you 'require fcgi.rb', which is an
option.  remember the package ships with a ruby and c impl.

> I removed install_traps and sent a kill -PIPE to the spawned process and it
> didn't seem to blink, so I think it's not actually necessary (but perhaps it
> is with the pure Ruby version of fcgi)

which is what i tested with...

> A few other points:
>
> * you call '@@server.close' but this ties you to the pure-Ruby
> implementation; I am using the C version and it doesn't set such an instance
> variable. This means you can get warnings logged such as
>
> mod_fcgi.rb:in `install_traps': uninitialized class variable @@server in MOD_FCGI (NameError)

see above.

> * the trapping of TERM and HUP doesn't work properly for me. What happens is
> that if I send such a signal to the process, nothing happens (ps shows the
> same pid) until the next HTTP request comes along, at which point it fails
> and Apache returns '500 Internal Server Error'. The process is then
> restarted and it's fine thereafter.

silly question but above you said

> I removed install_traps and sent a kill -PIPE to the spawned process and it

you did put it back in right?  the described behaviour sound like you did not,
though i suspect you did... ;-(

> I put some file debugging in:
>
>   $stderr = File.open("/tmp/errs","a")
>   $stderr.sync = true
>   ...
>
>   trap('SIGHUP') do
>     $stderr.puts "#{Time.now} signals #{@@signals.inspect} handling_request #{@@handling_request.inspect} exit_requested #{@@exit_requested.inspect}"
>   ...
>
> What seems to happen is that the trap handler is not even started until the
> subsequent request comes in, as shown by the timestamp. The process *then*
> commits suicide (since @@handling_request is still false at that point) and
> the 500 error occurs. Changing 'exit' to 'exit!' doesn't make any difference
> either.
>
> It's as if the signal is held up in accept() until the next incoming
> connection arrives. I can't work out why this is the case, but for now just
> removing 'install_traps' actually gives me much better results, since the
> process just dies and is respawned straight away.
>
> FYI I am running ruby 1.6.8 (2002-12-24) [i386-freebsd4.7] with
> ruby-fcgi-0.8.1 + fcgi-2.4.0, apache-1.3.27, mod_fastcgi-2.2.12
>
> * I also had to make a few changes to make it load cleanly under ruby -w
> (attached)

i will need to drink more coffee and think about this... signals are so
simple, err... confusing, no simple, no confusing...

> Otherwise this all looks very cool, and I actually don't think that it's
> Apache-specific. SIGPIPE isn't an Apache extension to fastcgi spec, it just
> closes the socket if it isn't interested in waiting for the response, and
> the OS generates SIGPIPE. Other fastcgi servers are likely to do the same.
>
> As a result, I think that what you've written really belongs in the core
> FCGI library anyway, i.e.
>
>   - bootstrapping of a CGI object (maybe FCGI.each_cgi ?)
>
> and perhaps also optional graceful shutdown on USR1, if it can be made to
> work (although that _is_ an Apache feature)
>
> Or else at least it can go on the RubyGardenWiki ?
>
> Regards,
>
> Brian.
>
> P.S. Thinking about USR1, I just checked and libfcgi does install a USR1
> handler (which sets an interal flag for a graceful abort). However it
> doesn't work very well if the process is between requests, because it just
> sits in accept() and catches the signal, so doesn't abort until the next
> incoming connection occurs, giving a 500 error to the client.

yes to all of the above.  i had hoped that someone else (more than one) would
test it out and make further mods.  i think this small peice of code (fastcgi
- not my peice!) is more usefull than alot of the huge app server type
projects out there and a few simple fixes like being able to obtain a
'normal' cgi object, and therefore be able to use a known api, and having the
fastcgi processes behave nicely with signals (to reload and all that) could
make this approach really attractive.  IMHO fastcgi seems to overcome all
that shortcomings of cgi programming (persistence, speed, etc) while adding
only a small amount of complexity (signals, etc).  in addition to that, the
code involved in implementing a fastcgi lib is so simple even idiots like me
can (sortof) understand it!

i'll try out your mods on my setup next week and get back to you.  if you (or
anyone else) are interested we should keep bouncing ideas of off each other
untill we have something viable, doccument it, and either release it ourselves
or contribute to the present fcgi project.  i would love to see this
technology gain some momentum in the ruby community.

thanks for the significant work.

-a



--
  ====================================
  | Ara Howard
  | NOAA Forecast Systems Laboratory
  | Information and Technology Services
  | Data Systems Group
  | R/FST 325 Broadway
  | Boulder, CO 80305-3328
  | Email: ahoward / fsl.noaa.gov
  | Phone:  303-497-7238
  | Fax:    303-497-7259
  ====================================