Forum: Ruby Problem with Daemon written in ruby...

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
6f37c32b62670cb9a5ac0330cb27269a?d=identicon&s=25 steve_rubytalk (Guest)
on 2005-11-18 15:42
(Received via mailing list)
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:in `wait'
        from /usr/lib/ruby/1.8/net/imap.rb:966:in `get_tagged_response'
        from /usr/lib/ruby/1.8/net/imap.rb:1022:in `send_command'
        from /usr/lib/ruby/1.8/monitor.rb:229:in `synchronize'
        from /usr/lib/ruby/1.8/net/imap.rb:1007:in `send_command'
        from /usr/lib/ruby/1.8/net/imap.rb:1140:in `search_internal'
        from /usr/lib/ruby/1.8/monitor.rb:229:in `synchronize'
        from /usr/lib/ruby/1.8/net/imap.rb:1136:in `search_internal'
        from /usr/lib/ruby/1.8/net/imap.rb:675:in `search'
        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?
42c83263598da02c136a4ebf8a058182?d=identicon&s=25 akr (Guest)
on 2005-11-18 16:49
(Received via mailing list)
In article <437DE7CF.4000703@shic.co.uk>,
  "Steve [RubyTalk]" <steve_rubytalk@shic.co.uk> 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.
D14cf036a5a4430617387d3a14c152d0?d=identicon&s=25 rick (Guest)
on 2005-11-18 23:46
(Received via mailing list)
On Sat, Nov 19, 2005 at 12:46:06AM +0900, Tanaka Akira 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 Akira

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
6f37c32b62670cb9a5ac0330cb27269a?d=identicon&s=25 steve_rubytalk (Guest)
on 2005-11-19 20:50
(Received via mailing list)
Tanaka Akira wrote:
> "Steve [RubyTalk]" <steve_rubytalk@shic.co.uk> 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.
This topic is locked and can not be replied to.