[Win32utils-devel] win32-daemon 0.6.1 problem

Park Heesob phasis at gmail.com
Fri Oct 31 20:13:38 EDT 2008


----- Original Message ----- 
From: "Berger, Daniel" <Daniel.Berger at qwest.com>
To: "Development and ideas for win32utils projects" 
<win32utils-devel at rubyforge.org>
Sent: Saturday, November 01, 2008 1:12 AM
Subject: Re: [Win32utils-devel] win32-daemon 0.6.1 problem


>> >
<snip>
>> In my test, I found two problems in the above demon.rb .
>> First, your environment may has RUBYOPT and raised following error.
>> ruby: no such file to load -- ubygems (LoadError)
>
> I tried unsetting RUBYOPT on the command line and setting it to nil from
> within the daemon itself, but it still didn't work. I also don't get any
> output to the log file.
>
>> I have workarounded by modifing "RUBYOPT" to "RUBYOPTX" in
>> ruby.c #755.
>
> Eep! That seems a bit extreme. I wouldn't think we would need to.
>
Did you try it? You must have log file of size 0 when the log file does not 
exist.
It is a proof of passing RUBYOPT barrier.

>> Second, STDIN.close in demon.rb raise error.
>> In my thought, STDIN.close is just a meaningless code.
>
> Yeah, it was just me experimenting mostly. Removing it didn't help,
> though.
>
In Demon's rescue part, try LOG_HANDLE.print instead of puts to print error.

> On a related note, I've been thinking that perhaps Daemon.new should
> take an optional log file. If present, have STDERR and STDOUT reopen on
> that file instead of NUL. It would be the users job to properly close
> the handle in the service_stop method, although perhaps we could setup a
> finalizer.
>
> Does that sound like a good idea?
>
It seems a good idea.
Another possible option is using the win32-eventlog instead of the log file.

> Anyway, still no luck with running the Daemon itself. Now that we have
> callbacks working better in win32-api, I'm hoping to revisit the pure
> Ruby Win32::Daemon class again. :)
>
It would be better to have pure Ruby version.
But in this case, I have success to start Daemon.
You should find out why it fails to work. :)

Regards,

Park Heesob




More information about the win32utils-devel mailing list