I''ve just had a problem with fastcgi killing processes off while they
were running (I have a long-running background process)... but it took
me a while to track it down and pinpoint that fastcgi was asking the
process to quit. So i was thinking if it would be a good idea to tweak
the way ruby-fastcgi handles this.
At the moment, in fcgi.rb (part of the fcgi gem) there is
trap("SIGTERM") { exit }
on line 10 or so, and SIGTERM is sent by the apache-fcgi module when it
asks a process to stop. would it not be better to set a flag or
something, so that the process can finish what it is doing - then exit
instead of handling another request - rather than exiting immediately?
Does this make any sense to anyone? Is this anywhere near a good idea?
or do i need more sleep? :)
Bodhi
Well if what you say is true, then I totally agree. (I don''t know enough about FastCGI yet). From a functional standpoint it seems like you would want to set a flag so the processes can exit on their own accord but then after a time limit has passed then go ahead and kill the process (assuming it was hung). This would allow things to complete and cleanup to be done before simply killing things half baked. Hopefully someone more familiar with FastCGI and fcgi.rb can confirm.
On 10/05/05, bodhi <bodhi-DrnEsRrc7Su2oZ/6fjIToQ@public.gmane.org> wrote:> I''ve just had a problem with fastcgi killing processes off while they > were running (I have a long-running background process)... but it took > me a while to track it down and pinpoint that fastcgi was asking the > process to quit. So i was thinking if it would be a good idea to tweak > the way ruby-fastcgi handles this. > At the moment, in fcgi.rb (part of the fcgi gem) there is > > trap("SIGTERM") { exit } > > on line 10 or so, and SIGTERM is sent by the apache-fcgi module when it > asks a process to stop. would it not be better to set a flag or > something, so that the process can finish what it is doing - then exit > instead of handling another request - rather than exiting immediately? > > Does this make any sense to anyone? Is this anywhere near a good idea? > or do i need more sleep? :)It almost makes sense, but SIGTERM is normally understood to mean ''die sometime in the next few seconds or you''ll be killed'', and if Rails is in the middle of a long operation you''re going to have problems. I''m guessing that exit will close all connections and rollback transactions if applicable, so this is probably the best way of doing it. -- Phillip Hutchings http://www.sitharus.com/ sitharus-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org / sitharus-QrR4M9swfipWk0Htik3J/w@public.gmane.org
This functionality used to be available in ruby-fcgi 0.8.4. When you do> apachectl gracefuleach fcgi process receives SIGUSR1 and ruby-fcgi captures this event and exits process after the latest request is complete. Then for some reason this functionality was removed. AFAIK, the similar logic is now available in SVN version of Rails. Kent. On 5/10/05, Jeff Barczewski <jeff.barczewski-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:> Well if what you say is true, then I totally agree. (I don''t know > enough about FastCGI yet). From a functional standpoint it seems like > you would want to set a flag so the processes can exit on their own > accord but then after a time limit has passed then go ahead and kill > the process (assuming it was hung). This would allow things to > complete and cleanup to be done before simply killing things half > baked. > > Hopefully someone more familiar with FastCGI and fcgi.rb can confirm. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
> > It almost makes sense, but SIGTERM is normally understood to mean ''die > sometime in the next few seconds or you''ll be killed'', and if Rails is > in the middle of a long operation you''re going to have problems. > > I''m guessing that exit will close all connections and rollback > transactions if applicable, so this is probably the best way of doing > it.It cleans up nicely, but it just terminates my thread... The signal is sent from the fcgi process manager when it decides that it has too many processes running, not when apache is shutting down... I guess the best approach for me would be to fork a new ruby process.
what kind of traffic are you getting? are there any howtos or documentation on managing high (or medium, or small depending on your experience) traffic applications with rails? say like 70k uniques per day? On 5/10/05, bodhi <bodhi-DrnEsRrc7Su2oZ/6fjIToQ@public.gmane.org> wrote:> > > > It almost makes sense, but SIGTERM is normally understood to mean ''die > > sometime in the next few seconds or you''ll be killed'', and if Rails is > > in the middle of a long operation you''re going to have problems. > > > > I''m guessing that exit will close all connections and rollback > > transactions if applicable, so this is probably the best way of doing > > it. > > It cleans up nicely, but it just terminates my thread... The signal is > sent from the fcgi process manager when it decides that it has too many > processes running, not when apache is shutting down... > > I guess the best approach for me would be to fork a new ruby process. > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On 11/05/2005, at 1:29 PM, Caleb Buxton wrote:> what kind of traffic are you getting? are there any howtos or > documentation on managing high (or medium, or small depending on your > experience) traffic applications with rails? say like 70k uniques per > day? >The ruby app isnt getting high-traffic, but it has to send a few thousand customised emails out several times a week, which takes a few hours each time, this process is terminated by fcgi. i''ve managed to get around it by adding FastCgiConfig -killInterval 72000 to my apache config file. I''d also like to see a howto for getting a high-traffic server up and running with rails... I might do one myself, if i can find the time...> On 5/10/05, bodhi <bodhi-DrnEsRrc7Su2oZ/6fjIToQ@public.gmane.org> wrote: >>> >>> It almost makes sense, but SIGTERM is normally understood to mean >>> ''die >>> sometime in the next few seconds or you''ll be killed'', and if Rails >>> is >>> in the middle of a long operation you''re going to have problems. >>> >>> I''m guessing that exit will close all connections and rollback >>> transactions if applicable, so this is probably the best way of doing >>> it. >> >> It cleans up nicely, but it just terminates my thread... The signal >> is >> sent from the fcgi process manager when it decides that it has too >> many >> processes running, not when apache is shutting down... >> >> I guess the best approach for me would be to fork a new ruby process.
On Wed, May 11, 2005 at 02:28:44PM +0900, bodhi wrote:> The ruby app isnt getting high-traffic, but it has to send a few > thousand customised emails out several times a week, which takes a few > hours each time, this process is terminated by fcgi. > > i''ve managed to get around it by adding > > FastCgiConfig -killInterval 72000 > > to my apache config file.If you''re spawning an external process, then you need to call Process#setsid in the child. That will stop it being part of the same process group as the parent. You''ll also probably want to close the FCGI socket that it''s taking requests on. Generally, you need to read up on forking a daemon process under Unix. This seems to cover most aspects you''ll need: http://www.enderunix.org/docs/eng/daemon.php I have no idea how all this works on win32. -Dom
> If you''re spawning an external process, then you need to call > Process#setsid in the child. That will stop it being part of the same > process group as the parent. > > You''ll also probably want to close the FCGI socket that it''s taking > requests on. > > Generally, you need to read up on forking a daemon process under Unix. > This seems to cover most aspects you''ll need: > > http://www.enderunix.org/docs/eng/daemon.php > > I have no idea how all this works on win32.Thanks for the link, but in my case I''m just using ruby threads (eg Thread.new do blah)... I havent really investigated how much it affects that process''s ability to handle cgi requests, but its not important, as the mailing system only really has one user (its main function is the mail sending). At some point, i''ll look into how using separate threads affects the performance of it all, but not now, I''m too busy! Bodhi