Problem with Daemon written in ruby

Ruby
1

I recently asked about daemonizing a process in ruby and, in brief, I
was told to close I/O handles and use fork and Process.setsid. [It was
only a surprise that in Ruby 1.8 I have to do this by hand rather than
use a library.] While all seemed to work absolutely fine with a few
toy examples, I’ve run into a difficulty when I try to wrap my existing
process (which works just fine running in a single process without
fork.)

Whenever I do “processing” after fork I get the following error
message… it seems to relate to thread management in the net/imap
implementation in the standard library. I make no explicit use of
threads in myprog.rb:

–
/usr/lib/ruby/1.8/monitor.rb:98:in stop': stopping only thread (ThreadError) note: use sleep to stop forever from /usr/lib/ruby/1.8/monitor.rb:98:inwait’
from /usr/lib/ruby/1.8/net/imap.rb:966:in get_tagged_response' from /usr/lib/ruby/1.8/net/imap.rb:1022:insend_command’
from /usr/lib/ruby/1.8/monitor.rb:229:in synchronize' from /usr/lib/ruby/1.8/net/imap.rb:1007:insend_command’
from /usr/lib/ruby/1.8/net/imap.rb:1140:in search_internal' from /usr/lib/ruby/1.8/monitor.rb:229:insynchronize’
from /usr/lib/ruby/1.8/net/imap.rb:1136:in search_internal' from /usr/lib/ruby/1.8/net/imap.rb:675:insearch’
from ./myprog.rb:57:in `process’
from ./myprog.rb:93
from ./myprog.rb:88

Should I have expected this? What would be the best way to address the
problem? I don’t see why having used fork should have affected
threading. Can anyone explain?

2

In article [email protected],
“Steve [RubyTalk]” [email protected] writes:

Should I have expected this? What would be the best way to address the
problem? I don’t see why having used fork should have affected
threading. Can anyone explain?

  1. fork doesn’t copy other threads in the child process.
  2. fork+setsid daemonization kills the parent process.

So the daemon process has only the thread which calls fork.

Process.daemon in Ruby 1.9 may help you. It daemonize the
process without killing other threads.

3

On Sat, Nov 19, 2005 at 12:46:06AM +0900, Tanaka A. wrote:

So the daemon process has only the thread which calls fork.

Process.daemon in Ruby 1.9 may help you. It daemonize the
process without killing other threads.

Tanaka A.

Also, if your process needs to be a daemon, that should be the first
thing you
do. This will avoid problems with threads since you won’t have started
anything
that may be using them yet.

Other things you might think about is changing the process directory to
/. If
you don’t do this, you’ll find that you can’t umount the file system the
daemon
has as it’s current directory if you need to. By default, it’s current
directory
will be the current directory of the process that launched it. Maybe
your home
directory if you launched it by hand. I also always set the umask to
something
known since you don’t really know the environment that the program will
be run
from. These things can be especially important for a daemon since they
are
usually meant to run for the life of the system.

Good luck!

Rick

4

Tanaka A. wrote:

“Steve [RubyTalk]” [email protected] writes:

Should I have expected this? What would be the best way to address the
problem? I don’t see why having used fork should have affected
threading. Can anyone explain?

  1. fork doesn’t copy other threads in the child process.
    Thanks.

This (while obvious now) is exactly what I was overlooking… I had
assumed that merely connecting an net/imap object to a server would not
spawn any threads… and I was wrong. I still don’t see why the IMAP
implementation should need to do this in my case… but by moving all
IMAP access into the forked process the problem disappears. It is a
pity that I can’t straightforwardly connect (and report any connection
problems) before daemonizing - but I at least have a fix for now.

BTW - are there alternative IMAP implementations? The one in the
standard library (apart from spawning threads which I’d prefer it
didn’t) appears to have no support for the IDLE command… which is a
pity as such a feature would be a valuable enhancement for my purposes.