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

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

I have a windows service issue that I would like some suggestions on a problem that we are seeing. I have a perl program that uses the net::server module that basicly monitors a port. <It waits for someone to open the port to communicate with it and tell it to run different tasks. These tasks are ran using a system("start <cmd>"). One of the tasks that the program will do is to build and package one of our companies products.
use base qw(Net::Server); ... ... MyPackage->run(port => 2000, log_file => ser.log, log_level => 4); and then it does: system("start build.pl");
to start a build on the local system.

If you run this as a stand-a-lone process it will open up a msdos window and runs the build.pl program in it and you see the output of the build.pl script as it goes through the build process.

I then use the serany.exe program to run this program as a service. This works for us as I can now remotely talk to the system using tcp and do not have to log into the system to do a build.

The problem is that when we run this as a service the program is disconected from the console and we no longer get a window that pops up on the conosle.

Is there anyway we can change/replace the "system()" command so that a window will open up on the console with the build output?

Replies are listed 'Best First'.
Re: Windows service Question
by redgreen (Priest) on Oct 01, 2009 at 21:01 UTC
    If you go into the Windows services (from Administration Tools), right click the service you are running, selecting 'Properties'. Then, select the 'Log On' tab. Is the 'Allow service to interact with desktop' option selected?
Re: Windows service Question
by bv (Friar) on Oct 02, 2009 at 01:12 UTC

    2nd the post above, but if you are running something as a Windows service, you should be aware that you could be introducing a privilege escalation vulnerability. If a user on the system can change the configuration of your service and cause it to run as SYSTEM, they can run any code they want at that privilege. Luckily, locking it down is easy using the built-in SC.EXE. The best reference I've seen on the subject is Best practices and guidance for writers of service discretionary control lists from Microsoft.

    print pack("A25",pack("V*",map{1919242272+$_}(34481450,-49737472,6228,0,-285028276,6979,-1380265972)))