renodino has asked for the wisdom of the Perl Monks concerning the following question:

(Using AS Perl 5.8.6, WinXP Pro)

I'm installing a Perl app as a Win32 Service via Win32::Daemon. Got that all working fine (tho ithreads seem to be doing odd things).

However, when I open the Control Panel->Administrative Tools->Services tool and check on the Recovery properties, they all indicate "Take no action" when the service fails. I'd like to have the service simply restart (up to 3 times, then fail hard). I can't find any i/f to Win32::Daemon::CreateService() to specify that behavior.

Does anyone know of a hash parameter to specify that recovery behavior ?

Update:

After some research, I've discovered the short answer is, "No.".

According to this, setting the the autorecovery actions requires an API call that grep indicates doesn't exist in Win32::Daemon. So either I hack Win32::Daemon, or I just tell my users to open the Admin->Service tool and set things themselves. <sigh/>. Guess it'll be the latter, as I don't have time for the former.

  • Comment on Win32::Daemon::CreateService to set autorecovery ?

Replies are listed 'Best First'.
Re: Win32::Daemon::CreateService to set autorecovery ?
by hackdaddy (Hermit) on Dec 16, 2005 at 08:07 UTC
    I'm using Win32::Daemon for a Win32 Service too on Windows Server 2003. There seems to be a problem with using threads and Win32::Daemon. Let me know if you find out more. I'm currently on another project at work, but will return to the Perl script Windows Service in January. So far Win32::Daemon works great. It just doesn't seem to play well with threads. Also the service never restarts if it crashes.
[reply]
      I've found my issue with threads and Win32::Daemon is related to threads::shared objects losing their tie after StartService is called; see Odd threads::shared behavior within a Win32::Daemon app for details.

      You may find that encapsulating all the Win32::Daemon stuff within its own thread may limit the overall impact of the issue, tho communicating stop/pause/resume events between the container and the rest of the app becomes problematic when you can't use threads::shared structures 8^{.

[reply]
        C# is somewhat Perlish. (Well, I say that for any language that has a foreach loop.)

        I've written Windows Services in C# before and it's rather straightforward. However, if you plan to write an installer for .NET Windows Services, that's another story. You have to reverse engineer working MSI's with Orca to see what the Visual Studio setup project is doing if you are building your project outside of Visual Studio. (Undocumented stuff, of course.)

        Also there's a bug in v1.1 of .NET which causes deadlock when loading a DLL with .NET and native code. One too many entry points for the load libary call and your program just locks up. Nice... How the hell did they decide to ship .NET with that bug?

[reply]

Back to Seekers of Perl Wisdom