Re: Servolux: monitoring outside change?

On Jan 10, 2012, at 9:07 PM, Aldric Giacomoni wrote:

> Thanks for the answer. I decided to try that behavior, and here is the
> result (sadly, negative). I must be doing something wrong... But what?
> Ruby 1.8.7-p357:
> $ pry
> [1] pry(main)> require 'servolux'
> => true
> [2] pry(main)> x = Servolux::Child.new :command => "sleep 600"
> => #<Servolux::Child:0xb7024290
> @command="sleep 600",  @io=nil, @pid=nil,
> @signals=["TERM", "QUIT", "KILL"], @status=nil,
> @suspend=4, @thread=nil, @timed_out=nil, @timeout=nil>
> [3] pry(main)> x.start
> => #<IO:0xb701c6bc>
> [4] pry(main)> x.pid
> => 17152
> 
> (at this point, I do a $ kill -9 17152 in another terminal)
> 
> [5] pry(main)> x.signaled?
> => nil
> [6] pry(main)> x.termsig
> => nil
> 
> Same test with Ruby 1.9.2-p290:
> 
> $ pry
> [1] pry(main)> RUBY_VERSION
> => "1.9.2"
> [2] pry(main)> require 'servolux'
> => true
> [3] pry(main)> x = Servolux::Child.new :command => "sleep 600"
> => #<Servolux::Child:0x84d68c4
> @command="sleep 600",
> @io=nil,
> @pid=nil,
> @signals=["TERM", "QUIT", "KILL"],
> @status=nil,
> @suspend=4,
> @thread=nil,
> @timed_out=nil,
> @timeout=nil>
> [4] pry(main)> x.start
> => #<IO:fd 3>
> [5] pry(main)> x.pid
> => 17614
> 
> (again, kill -9 17614 in another terminal)
> 
> [9] pry(main)> x.signaled?
> => nil
> [10] pry(main)> x.termsig
> => nil
> 
> In both situations, doing a 'ps eax | grep sleep' revealed the following:
> 17614 pts/5    ZN+    0:00 [sleep] <defunct>
> 
> Exiting the irb/pry session lets the sleep process finally die a peaceful
> death.
> 
> Would this count as a bug in Servolux?
> 

You need to reap the child PID otherwise you'll end up with a zombie process. You do this by calling Process.wait on the child PID. The Servolux::Child class has this built in via the wait method.


require 'servolux'
child = Servolux::Child.new :command => 'sleep 600'
child.wait
# now kill -9 the child process in a separate window
child.signaled?  #=> true
child.termsig    #=> 9


Hope that explains it a little more. Ruby has no way to know if the child process has been killed or not until you attempt to access the child again. Calling the wait method will cause Ruby to refresh it's knowledge of the child.

Blessings,
TwP


> --Aldric
> 
> On Tue, Jan 10, 2012 at 21:44, Tim Pease <[e-mail]> wrote:
> 
>> 
>> On Jan 10, 2012, at 1:05 PM, Aldric Giacomoni wrote:
>> 
>>> Hi Tim,
>>> 
>>> I started using Servolux on a small internal project and so far I'm
>> really
>>> pleased with it. What I'm doing is very simple: I have to manage a few
>>> scripts and start them with the right command-line arguments (does the
>>> acronym CLA mean anything to anyone? I've never seen it used but it would
>>> make my life so much easier). I use Servolux::Child objects for that.
>>> 
>> 
>> I'm glad you are finding Servolux useful!
>> 
>>> Is there a way, internally, to know whether one of the processes handled
>> by
>>> the Child object has been kill-9'd by, say, an outside human hand? I
>> don't
>>> really know enough about the popen stuff and process communication to
>>> figure that out.
>>> 
>> 
>> The Servolux::Child class provides several methods to determine the status
>> of the child process.
>> 
>> * alive? -- This method returns +true+ if the child process is still
>> alive. So if someone kills the process (kill -9) then this method will
>> return +false+. If this method returns +nil+, the the child process was
>> never started.
>> 
>> There are several methods that map directly to the ruby Process::Status
>> class and can be used to find out exactly how and why the child process
>> exited. All of these methods can be called on your Servolux::Child instance:
>> 
>> * coredump?
>> * exited?
>> * signaled?
>> * stopped?
>> * success?
>> * exitstatus
>> * stopsig
>> * termsig
>> 
>> You can read the documentation for these methods here =>
>> http://ruby-doc.org/core-1.9.3/Process/Status.html
>> In your case the methods to look at are "signaled?" and "termsig". If
>> "termsig" returns 9, then someone used kill -9 to stop the process.
>> 
>> Hope all this helps!
>> 
>> Blessings,
>> TwP