From: David Masover <ninja@...>
Date: 2009-12-13T04:43:32+09:00
Subject: Re: Is it possible to force a Ruby program to run as a proc name different than "ruby"?

On Saturday 12 December 2009 03:53:06 am Iñaki Baz Castillo wrote:

> Well, usually daemons are coded to deelte the pidfile upon receipt of a
>  SIGINT signal (or some others). But if the daemon is killed with "kill -9
>  PID" then it terminates inmediately without deleting the piddile.

True. I tried (and failed) to find an example of this working. However, a 
separate process can watch your process and clean up after it however it dies. 
I think this is the principle behind letting init handle it -- take "upstart".

> In the case of a crash or segmentfault the daemon wouldn't delete the
>  pidfile again.

If the crash raises an exception, you can catch that. Segmentation faults 
trigger SIGSEGV, which you can trap. I suspect you'd have a chance to at least 
fire that unlink call with any death except a 'kill -9'.

> > I can think of a few other possibilities, like checking directly (with
> >  fuser, for example) which process is controlling the resource your
> > daemon is associated with, or even talking to the old daemon over a
> > socket, or some sort of formal IPC like dbus.
> 
> Sounds interesting, but perhaps a bit complex. I think I don't need so much
>  as there will be an unique instance of the ruby program running in the
>  server.

Yes, probably too complex to do for a specific program. However, it might be 
worth wrapping into a library, if there isn't already one designed for this.

> Thanks a lot for all your suggestions, it's a really interesting subject.
> However I would prefer to keep the code as simple as possible. The only I
> wanted was the possibility of kill my program using "killall rb_program".
> 
> To summarize this is possible in these cases:
> 
> a) Hardcoding the ruby location (avoiding using "env").
> Not user-friendly.

However, if you distribute your app as a gem, this problem actually goes away. 
Here's the top of gems/rake-0.8.7/bin/rake:

#!/usr/bin/env ruby

#--
# Copyright (c) 2003, 2004, 2005, 2006, 2007  Jim Weirich
...

Here's what it actually installs into your PATH:

#!/usr/bin/ruby1.9.1
#
# This file was generated by RubyGems.
#
# The application 'rake' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'

version = ">= 0"

if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
  version = $1
  ARGV.shift
end

gem 'rake', version
load Gem.bin_path('rake', 'rake', version)



So, that gives you the best of both worlds -- it's actually somewhat like one 
of the crazier solutions I suggested.

> b) Creating a link "rb_program" to ruby interpreter and invoke my program
>  with "rb_program /PATH_TO_rb_program.rb".
> Not very beauty :)
> 
> c) Replacing env with your above suggestion.

Except (c) doesn't work. I thought it would work, and I posted it to the list 
in case I was close enough for someone to pick up where I left off.

> It involves compiling a C program, it could break something in a not pure
> Linux environment...

Well, the idea was that if this worked, it'd be generally useful. After all, 
env is on every system, and many Ruby scripts rely on that. So again, not 
something specific to your program.