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'
> =3D> true
> [2] pry(main)> x =3D Servolux::Child.new :command =3D> "sleep 600"
> =3D> #<Servolux::Child:0xb7024290
> @command=3D"sleep 600",  @io=3Dnil, @pid=3Dnil,
> @signals=3D["TERM", "QUIT", "KILL"], @status=3Dnil,
> @suspend=3D4, @thread=3Dnil, @timed_out=3Dnil, @timeout=3Dnil>
> [3] pry(main)> x.start
> =3D> #<IO:0xb701c6bc>
> [4] pry(main)> x.pid
> =3D> 17152
>=20
> (at this point, I do a $ kill -9 17152 in another terminal)
>=20
> [5] pry(main)> x.signaled?
> =3D> nil
> [6] pry(main)> x.termsig
> =3D> nil
>=20
> Same test with Ruby 1.9.2-p290:
>=20
> $ pry
> [1] pry(main)> RUBY_VERSION
> =3D> "1.9.2"
> [2] pry(main)> require 'servolux'
> =3D> true
> [3] pry(main)> x =3D Servolux::Child.new :command =3D> "sleep 600"
> =3D> #<Servolux::Child:0x84d68c4
> @command=3D"sleep 600",
> @io=3Dnil,
> @pid=3Dnil,
> @signals=3D["TERM", "QUIT", "KILL"],
> @status=3Dnil,
> @suspend=3D4,
> @thread=3Dnil,
> @timed_out=3Dnil,
> @timeout=3Dnil>
> [4] pry(main)> x.start
> =3D> #<IO:fd 3>
> [5] pry(main)> x.pid
> =3D> 17614
>=20
> (again, kill -9 17614 in another terminal)
>=20
> [9] pry(main)> x.signaled?
> =3D> nil
> [10] pry(main)> x.termsig
> =3D> nil
>=20
> In both situations, doing a 'ps eax | grep sleep' revealed the =
following:
> 17614 pts/5    ZN+    0:00 [sleep] <defunct>
>=20
> Exiting the irb/pry session lets the sleep process finally die a =
peaceful
> death.
>=20
> Would this count as a bug in Servolux?
>=20

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 =3D Servolux::Child.new :command =3D> 'sleep 600'
child.wait
# now kill -9 the child process in a separate window
child.signaled?  #=3D> true
child.termsig    #=3D> 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
>=20
> On Tue, Jan 10, 2012 at 21:44, Tim Pease <[e-mail]> wrote:
>=20
>>=20
>> On Jan 10, 2012, at 1:05 PM, Aldric Giacomoni wrote:
>>=20
>>> Hi Tim,
>>>=20
>>> 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.
>>>=20
>>=20
>> I'm glad you are finding Servolux useful!
>>=20
>>> 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.
>>>=20
>>=20
>> The Servolux::Child class provides several methods to determine the =
status
>> of the child process.
>>=20
>> * 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.
>>=20
>> 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:
>>=20
>> * coredump?
>> * exited?
>> * signaled?
>> * stopped?
>> * success?
>> * exitstatus
>> * stopsig
>> * termsig
>>=20
>> You can read the documentation for these methods here =3D>
>> 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.
>>=20
>> Hope all this helps!
>>=20
>> Blessings,
>> TwP