in reply to Re: Win32::Daemon + IPC::Run redirect problem
in thread Win32::Daemon + IPC::Run redirect problem

To maybe clarify a bit more about what the OP said...

The OP combined the Windows "Service installation program" and the "Service itself" into one file. This is fine although often this would be 2 separate programs. The installation option makes entries into the Windows Registry about this new service and then exits - that is all it does.

A Windows service is like a unix daemon. This is a process that runs "in the background" with no connection to a command line terminal. There are many examples of things like that. A database server would be an example.

I have verified that the installation part "works". The service is "installed" and looks normal to the Windows O/S. I can start the service with the "net start" command or from the GUI.

The issue here is how to run an external program and get its result from the Service environment? The service is not started from a command line shell and doesn't have connections to STDOUT,STDERR,STDIN. I found that I could use backticks to run the ping program and get the output of ping although I was not able to get ping to work with run() or run3().

So I found a way to get ping into the Service's log, but this is only a partial solution. This is an question about the environment that the service is running in.

  • Comment on Re^2: Win32::Daemon + IPC::Run redirect problem

Replies are listed 'Best First'.
Re^3: Win32::Daemon + IPC::Run redirect problem
by chris212 (Scribe) on May 08, 2017 at 20:24 UTC
    Yes, I found the same (IPC::Run and IPC::Run3 cannot redirect, backticks and system can). The issue is I was looking at making a Perl script a service which would call other scripts (components). Many of which will use IPC::Run. I don't want to have to convert all the components which use IPC::Run losing the benefits of that module which are probably needed in some cases, and I don't want to impose a limitation on components due to running as a service. Unless there is an easy workaround or a bug fix on the horizon to avoid losing any component functionality, I don't think this is worth me pursuing.

      The service is not started from a command line shell and doesn't have connections to STDOUT,STDERR,STDIN.

      That could be the key to the problem. What if you tried opening them if they are not open yet. That way if somehow IPC::Run is failing because they dont exist yet, well now it has some to takeover when it needs to

        They are "open", so the service process has some kind of emulated STDOUT, but a stat on it will fail. If you close STDOUT, you can see the same behavior from a command-line. If you call another perl script (or itself) from the service script, that child process will work correctly.