http://qs321.pair.com?node_id=1168944


in reply to Background proc requires ENTER keystroke on Windows 2012

Since I can't easily reproduce the problem behavior, could you at least note what the bg server produces before you press Enter? If nothing (that is, if the "executing:" line is not printed until after you press Enter), then you should add more output so that you can narrow down where the hang is happening. If "executing:" is displayed before you hit Enter, do you have to hit Enter again in order to get a second request to finish?

- tye        

  • Comment on Re: Background proc requires ENTER keystroke on Windows 2012 (details)

Replies are listed 'Best First'.
Re^2: Background proc requires ENTER keystroke on Windows 2012 (details)
by stevieb (Canon) on Aug 02, 2016 at 00:56 UTC

    The latter, tye.

    "executing: ..." is displayed before I hit ENTER. This is after I see in Task Manager a new perl.exe process start up. Once it does, the "executing..." line is displayed, then I must hit enter for the entire process to proceed.

      You can probably prevent this problem by "backgrounding" your daemon the proper way, by daemonizing it. No, Proc::Background does not do that either.

      If you at least re-open STDIN, STDOUT, and STDERR to/from File::Spec->devnull() (or even have the last two append to some log file), then I will be a bit surprised if the daemon has the ability to ask for input from the calling context.

      Some of the daemonize modules might even know the right trick for completely disassociating the daemon from the parent's "console" (similar to what motivates the setsid() part of daemonizing on Unix). If not, you could try calling Free() in Win32::Console, though I don't recall having tried that and I have not swapped back in most of what little I used to know about Win32 "consoles".

      If I wanted to try and debug what is happening, then I'd probably next look for a compatible version of "process monitor" such as one from the former SysInternals.

      - tye        

        I see what you mean now tye regarding properly daemonizing the process compared to just putting it into the background.

        I'm looking at the daemon modules now, and will get some test code written later on today.