# Problem with Daemon written in ruby

**URL:** <https://www.ruby-forum.com/t/problem-with-daemon-written-in-ruby/48281>\
**Category:** Ruby\
**Created:** [November 18, 2005, 3:42pm UTC](https://www.ruby-forum.com/t/problem-with-daemon-written-in-ruby/48281 "2005-11-18T15:42:29Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![steve\_rubytalk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@steve\_rubytalk](https://www.ruby-forum.com/u/steve_rubytalk)\
**Post date:** [November 18, 2005, 3:42pm UTC](https://www.ruby-forum.com/t/problem-with-daemon-written-in-ruby/48281/1 "2005-11-18T15:42:29Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![steve\_rubytalk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@steve\_rubytalk](https://www.ruby-forum.com/u/steve_rubytalk)\
**Post date:** [November 18, 2005, 4:49pm UTC](https://www.ruby-forum.com/t/problem-with-daemon-written-in-ruby/48281/2 "2005-11-18T16:49:18Z")

</div>

In article [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid),  
“Steve [RubyTalk]” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.

---

<div class="post-metadata">

**Author:** ![steve\_rubytalk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@steve\_rubytalk](https://www.ruby-forum.com/u/steve_rubytalk)\
**Post date:** [November 18, 2005, 11:46pm UTC](https://www.ruby-forum.com/t/problem-with-daemon-written-in-ruby/48281/3 "2005-11-18T23:46:16Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![steve\_rubytalk](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/e495f1/32.png) [@steve\_rubytalk](https://www.ruby-forum.com/u/steve_rubytalk)\
**Post date:** [November 19, 2005, 8:50pm UTC](https://www.ruby-forum.com/t/problem-with-daemon-written-in-ruby/48281/4 "2005-11-19T20:50:17Z")

</div>

Tanaka A. wrote:

> “Steve [RubyTalk]” [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) 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.
