in reply to Re: Debugging Windows Services created with Win32::Daemon (STDERR)
in thread Debugging Windows Services created with Win32::Daemon

I'd redirect STDERR to a file (and probably do that in a BEGIN block near the top of the main script file).

Using Win32::EventLog in conjunction with a __DIE__ handler would perhaps be a better solution.

When Perl dies, it almost always says something on the way down. I suspect Win32 is just throwing this information away.

Wouldn't a pucker *nix daemon also throw away any parting STDERR output? The done thing is to close all the standard filestreams isn't it?

It's quite likely that (if enabled) any non-zero termination code or STDERR output would end up in the system or application portion of the event log

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.
  • Comment on Re^2: Debugging Windows Services created with Win32::Daemon (STDERR)

Replies are listed 'Best First'.
Re^3: Debugging Windows Services created with Win32::Daemon (STDERR)
by tye (Sage) on Nov 16, 2005 at 20:04 UTC
    Using Win32::EventLog in conjunction with a __DIE__ handler would perhaps be a better solution.

    If you define "better" as "still throws away lots of possible sources of information". Eventually, I'd do both. As a first step in figuring out what is going wrong, I'd go with the much simpler approach that catches stuff other than just die cases. To illustrate just one case: I wouldn't be at all surprised if Perl, after reporting "panic: ...", might not survive long enough to make it all the way to the end of the non-trivial number of opcodes required to catch then get stuff into the event log.

    Wouldn't a pucker *nix daemon also throw away any parting STDERR output? The done thing is to close all the standard filestreams isn't it?

    A production-quality daemon usually redirects STDERR to /dev/null (closing is a bad idea). But a Unix daemon who doesn't do this could end up with its output automatically going to the system log (or, on some older Unixes, to "the console"). On some old Unix configurations, this could actually cause problems. My comment wasn't meant to be a dig against Win32. I still suspect that Win32 is just throwing away the information. And sometimes that has its advantages. No need to get defensive. (:

    It's quite likely that (if enabled) any non-zero termination code or STDERR output would end up in the system or application portion of the event log

    What does "if enabled" mean? If there is a Win32 option to redirect daemon output to the event log, then hackdaddy would probably appreciate a pointer to it. He reports that such isn't happening for him.

    - tye        

[reply]

      I was thinking of the option on Settings->cotrolPanel->System->Advanced->Startup&Recovery->System failure->[X] Write an event to the system log.

      That logs messages like

      "Application popup: perl.exe - Application Error : The instruction at "0x280b1efe" referenced memory at "0x00000009". The memory could not be "read".

      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]

        Thank you.

        I suspect that won't catch output to STDERR nor non-zero exit status, but I have no proof [and so this node is mostly useless (except for the 'thank you') unless it prompts someone to discover such answers :) ]

        - tye        

[reply]

In Section Seekers of Perl Wisdom