Re: Servolux: monitoring outside change?

On Jan 11, 2012, at 9:51 AM, Aldric Giacomoni wrote:

> Daemons seemed to fit the bill: long-running process in the =
background.
>=20
> Sadly, I ran into an issue in my unit tests where the Daemon would =
actually
> run so fast that Ruby would miss the start of it. Since that's not =
going to
> happen in my configuration in real life, I just made the script run a
> little longer.
>=20
> Now, here is my current situation. Upon completion of a test where the
> Daemon.new.startup is called, the entire test suite stops running. The
> script runs properly. My unit test checks that upon completion, the =
script
> has done what it needs to do, so imagine this:
>=20
> def test_launches_outside_process
>  at_exit { assert_equal 100, Dir['/tmp/*'] }
>  Manager.new.launch {some =3D> args, here =3D> to, help =3D> out}
> end
>=20
> Now, the launch command:
> class Manager
>  def launch args
>    daemon =3D Servolux::Daemon.new :startup_command =3D> "/path/to/cmd =
with
> args", :name =3D> "name", :pid_file =3D> "/tmp/pid", :logger =3D>
> Logger.new('/tmp/log.log')
>    daemon.startup
>    at_exit { daemon.shutdown }
>   daemon
>  end
> end
>=20
> =46rom what I understand of the implementation, the daemon process, =
calling
> Kernel.exec, actually REPLACES the Ruby process. I realize it's =
supposed to
> fork up in the startup method, but ... How, then, can I use one single =
Ruby
> process to launch many daemons?
>=20
> I wrote a small script to identify my problem (maybe I'm thinking =
about it
> incorrectly):
> #!/usr/bin/env ruby
>=20
> require 'rubygems'
> require 'servolux'
> require 'logger'
>=20
> x =3D Servolux::Daemon.new :name =3D> 'hello', :logger =3D>
> Logger.new('/tmp/aldric.log'), :startup_command =3D> 'sleep 600', =
:pid_file
> =3D> '/tmp/aldric.pid'
> x.startup
> p "hello" while true
>=20
> This script does NOT print 'hello'. It returns to the command line and
> sleep is now running in the background.
>=20
> So.. If the Daemon object is really only meant to configure and start =
a
> daemon, then I -do- want a Child object, don't I.
> Thanks for the answer. The problem I have with calling 'wait' on the =
Child
> object is that I block my top-level process until I get more =
information
> from that child. I'm going to be in a situation where I have 20+ =
children
> all running. How can I monitor them all? Can I call Process.waitall =
and get
> the same result?
>=20

When you start the daemon, pass +false+ to the startup method. This will =
prevent exiting from the parent process after the daemon process is =
determined to be running.

http://rubydoc.info/gems/servolux/0.9.6/Servolux/Daemon:startup

Blessings,
TwP

> On Wed, Jan 11, 2012 at 11:10, Aldric Giacomoni <[e-mail]> =
wrote:
>=20
>> Oh, I see. What I want to use here is a daemon, not a child.
>>=20
>>=20
>> On Tue, Jan 10, 2012 at 23:07, Aldric Giacomoni <[e-mail]> =
wrote:
>>=20
>>> 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
>>> --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
>>>=20
>>>=20
>>>=20
>>=20