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?
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.
···
--
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
···
On Sat, Nov 19, 2005 at 12:46:06AM +0900, Tanaka Akira wrote:
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.
--
Tanaka Akira
--
Rick Nooner
rick@nooner.net
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.