# Ruby/Watchcat 1.0.0

**URL:** <https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481>\
**Category:** Ruby\
**Created:** [April 22, 2006, 1:05am UTC](https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481 "2006-04-22T01:05:29Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![reflex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f05b48/32.png) [@reflex](https://www.ruby-forum.com/u/reflex)\
**Post date:** [April 22, 2006, 1:05am UTC](https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481/1 "2006-04-22T01:05:29Z")

</div>

Hello

I’m pleased to announce the release of Ruby/Watchcat 1.0.0.

Ruby/Watchcat is an extension for Ruby for the development of  
watchcatd-aware applications.

Watchcatd is a watchdog-like daemon in the sense that it takes actions  
in situations where a machine is under heavy load and/or unresponsive.  
However, watchcatd isn’t as drastic as the usual watchdog systems, which  
reboot the machine. Instead, all it does is sending a signal to a  
registered process (which by default is SIGKILL) if the process doesn’t  
send it a heartbeat before a user-specified timeout.

Ruby/Watchcatd allows you to register ruby applications with watchcatd.

Examples:

require ‘watchcat’

# Create a new cat.

cat = Watchcat.new(:timeout =\> 10, :signal =\> ‘KILL’,  
:info =\> ‘killing from ruby!’)  
loop do  
# Here you do something that could exceed the timeout  
sleep 9 + rand(3)  
cat.heartbeat # we’re still alive  
end  
cat.close # clean the cat’s litter box

You can also use a block, in which case the cat cleans its own litter  
box:

require ‘watchcat’

Watchcat.new do |cat|  
loop do  
do\_something\_that\_can\_be\_slow  
cat.heartbeat  
end  
end

For more details, please refer to the README file in the distribution  
and  
in the project’s homepage at [http://oss.digirati.com.br/ruby-watchcat/](http://oss.digirati.com.br/ruby-watchcat/).

This is my first Ruby C extension, so I would greatly appreciate  
comments  
and suggestions 🙂

Best regards,  
Andre N.

---

<div class="post-metadata">

**Author:** ![reflex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f05b48/32.png) [@reflex](https://www.ruby-forum.com/u/reflex)\
**Post date:** [April 22, 2006, 4:05pm UTC](https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481/2 "2006-04-22T16:05:22Z")

</div>

On Sat, 22 Apr 2006, Andre N. wrote:

> Hello
> 
> I’m pleased to announce the release of Ruby/Watchcat 1.0.0.

so, in effect, this is a Timeout::timeout based on a child process?

look handy for some of the work i’m doing now - which is a 24x7  
satellite  
ingest system which spawns many processes which can potentially hang…

-a

---

<div class="post-metadata">

**Author:** ![reflex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f05b48/32.png) [@reflex](https://www.ruby-forum.com/u/reflex)\
**Post date:** [April 22, 2006, 6:33pm UTC](https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481/3 "2006-04-22T18:33:49Z")

</div>

Hi Ara

On Sat, 2006-04-22 at 23:03 +0900, removed\_email\_address@domain.invalid wrote:

> so, in effect, this is a Timeout::timeout based on a child process?

Yes, except that when the timeout expires, it triggers an action by the  
watchcat daemon (which by default SIGKILLs the process).

> look handy for some of the work i’m doing now - which is a 24x7 satellite  
> ingest system which spawns many processes which can potentially hang…

Our main use for it is in a shared hosting environment. We wrote a  
mod\_watchcat for apache2 and use watchcatd to kill misbehaving customer  
scripts (that has helped increasing our servers’ uptime a lot). When I  
wrote the extension, my idea was to use it for something similar, maybe  
with Mongrel, but I guess it would be useful for your satellite  
application too 🙂

Regards,  
Andre

---

<div class="post-metadata">

**Author:** ![reflex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f05b48/32.png) [@reflex](https://www.ruby-forum.com/u/reflex)\
**Post date:** [April 22, 2006, 7:57pm UTC](https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481/4 "2006-04-22T19:57:42Z")

</div>

Hmmm, me thinking…

On 4/21/06 7:03 PM, “Andre N.” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote:

> reboot the machine. Instead, all it does is sending a signal to a  
> registered process (which by default is SIGKILL) if the process doesn’t  
> send it a heartbeat before a user-specified timeout.

With Mongrel you’ve got the situation that a single Mongrel server could  
potentially be handling many requests at once, so killing off a dead one  
could really make things bad. But, in a shared hosting environment this  
would perfect for catching the poorly coded servers that eat up  
resources.

I kind of like this solution though since it is more difficult for the  
person to cheat. They can’t really turn it off by injecting Ruby code  
since  
they still have to talk to the watchcat. I’m curious if they could  
cheat  
other ways such as transferring the socket to another process which  
always  
works.

On another note, you know there’s options to for throttling and  
restricting  
the number of active threads in Mongrel right? -t will do a timeout  
(says  
seconds in the docs but it’s actually 1/100th of a second) between each  
socket accept. -n will make sure the number of processor threads  
doesn’t go  
above a given limit.

Zed A. Shaw

> **[Zed A. shaw](https://zedshaw.com/)**
>
> Personal essays and writings by Zed A. Shaw.

[http://mongrel.rubyforge.org/](http://mongrel.rubyforge.org/)

---

<div class="post-metadata">

**Author:** ![reflex](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/f05b48/32.png) [@reflex](https://www.ruby-forum.com/u/reflex)\
**Post date:** [April 22, 2006, 8:50pm UTC](https://www.ruby-forum.com/t/ruby-watchcat-1-0-0/58481/5 "2006-04-22T20:50:04Z")

</div>

Hi Zed

On Sun, 2006-04-23 at 02:53 +0900, Zed S. wrote:

> With Mongrel you’ve got the situation that a single Mongrel server could  
> potentially be handling many requests at once, so killing off a dead one  
> could really make things bad. But, in a shared hosting environment this  
> would perfect for catching the poorly coded servers that eat up resources.

Yes, the library is better suited for a multi-process model, like the  
pre-forking MPM in apache2, because we can just kill the process that is  
eating the resources without killing the whole server.

I’m actually not very familiar with Mongrel (just used it for a simple  
Camping app), although I’m planning to when time permits. I’m guessing  
that to make it work with Mongrel, one would need a wrapper script to  
launch the server, so that it could be relaunched after it’s killed.  
Does that make sense?

> I kind of like this solution though since it is more difficult for the  
> person to cheat. They can’t really turn it off by injecting Ruby code since  
> they still have to talk to the watchcat. I’m curious if they could cheat  
> other ways such as transferring the socket to another process which always  
> works.

In our environment, the user has no control of the watchcat (it is  
created by mod\_watchcat), so to pass the socket descriptor to another  
process the user would first have to guess what the descriptor is. It’s  
not impossible to do it, but then it would be easy for us to identify a  
user doing that.

Regards,  
Andre