Re: (tye)Re: Win32::Daemon

I recently used Win32::Daemon to create a connection between a Linux client and an NT database. It might have been quicker to use DBI::Proxy, but I learned more this way. I had some problems with my script, which might have been detected had I used something like this BEGIN block.

I deliberately added a line 'use Blarfle;' to my working script. Blarfle.pm does not exist (well, maybe it does on CPAN... I haven't looked). When I start my service from the control panel (NT 4.0), I get to watch an hour glass until it displays "Error 2186: The service is not responding to the control function."

I added this BEGIN block after the 'use Blarfle;' statement:

# *SNIP*
use Blarfle;

BEGIN {
    open(STDERR, ">>d:/daemon.err") or die "invisible error";
    warn "$0 started" . localtime() . "\n";
}

# *SNIP*

I didn't get any output in my d:\daemon.err file.

Next, I moved the 'use Blarfle;' so it was after the BEGIN block:

# *SNIP*
BEGIN {
    open(STDERR, ">>d:/daemon.err") or die "invisible error";
    warn "$0 started" . localtime() . "\n";
}

use Blarfle;

# *SNIP*

Again, I received Error 2186. However, I still didn't see any output in d:\daemon.err.

What did I miss?

Comment on Re: (tye)Re: Win32::Daemon

Replies are listed 'Best First'.
(tye)Re2: Win32::Daemon by tye (Sage) on Jun 19, 2001 at 09:43 UTC
Well, there are obvious things like not having a D: drive... But anything that would cause that open to fail would give that symptom, for example, perhaps the credentials of the service don't have access to append to that file (for example, if D: is a remote file system, then the service probably won't have any access to it no matter what permissions you set on the file). Or perhaps you were looking at the file using a tool that opened the file w/o specifying shared access so that the daemon couldn't open it. I'd first check that the script manages to write to the daemon.err file when run not as a service as well as when run as a service with the "user Blarfle;" line commented out. That should narrow things down quite a bit. You could also use try other methods for getting the "invisible error" to not be invisible such as: `open(...) or system( "net send %computername% " . qq("Can't open d:/daemon.err: $!; $^E") );` [download] (though I don't think that will work from a service either) or using something to pop up a message box (this should work if you configure the service to have access to the interactive desktop). It is sad that the WinNT Service Manager is so stupid when it comes to noticing and reporting that the service that it started has died. But then, if you look very far into the design of the service manager (called "the SCuM"), you quickly realize that it isn't a very good design in a lot of ways (just ask the guys who had to hack it to pieces to make it even usable for "clustering" -- "dogfood" indeed). /: - tye (but my friends call me "Tye")	[reply] [d/l]

Replies are listed 'Best First'.

(tye)Re2: Win32::Daemon
by tye (Sage) on Jun 19, 2001 at 09:43 UTC

Well, there are obvious things like not having a D: drive... But anything that would cause that open to fail would give that symptom, for example, perhaps the credentials of the service don't have access to append to that file (for example, if D: is a remote file system, then the service probably won't have any access to it no matter what permissions you set on the file).

Or perhaps you were looking at the file using a tool that opened the file w/o specifying shared access so that the daemon couldn't open it.

I'd first check that the script manages to write to the daemon.err file when run not as a service as well as when run as a service with the "user Blarfle;" line commented out. That should narrow things down quite a bit.

You could also use try other methods for getting the "invisible error" to not be invisible such as:

open(...)
  or  system( "net send %computername% "
        . qq("Can't open d:/daemon.err: $!; $^E") );
[download]

It is sad that the WinNT Service Manager is so stupid when it comes to noticing and reporting that the service that it started has died. But then, if you look very far into the design of the service manager (called "the SCuM"), you quickly realize that it isn't a very good design in a lot of ways (just ask the guys who had to hack it to pieces to make it even usable for "clustering" -- "dogfood" indeed). /:

tye

[reply]
[d/l]