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

Hi Fellow Monks, I'm a windows perl user, and have a script thats configured as a scheduled task (I'm unable to configure it as a win32 service at present).

The problem I'm facing is that my script (seemingly) randomly recieves INT or QUIT signals, and I don't know where they are coming from...

1. If possible, would someone mind replying with a piece of code that I can add to my signal handler that will trace where the signal came from?
2. If I choose to ignore these signals, what risks should I be aware of. And can I rely on a SIGKILL to terminate the script.

Appreciate any help.
Cheers, Des

Update:
Well, I cannot say for certain, but I'm still 99% sure of the following based on my testing:
Under windows, Perl ignores SIGQUIT (even the fake QUIT that it seemingly generates itself). Potentially due to my signal handler fidling with things. (I should of posted this before, sorry) In one sense, this handler 'upgrades' all signals to die... which I wanted initially when I was trying to locate the source of the signals.

use sigtrap qw(handler SIG_handler any normal-signals any error-signal +s); #### sub SIG_handler { my($signal) = @_; my $filename = 'signals.log'; my $num = threads->tid(); my $timestamp = scalar localtime(time); open (my $LOGFILE, ">>", $filename); print {$LOGFILE} "==$timestamp==\nThread $num caught/received a Si +gnal: [$signal]"; print {$LOGFILE} "\n\n\n"; close ($LOGFILE); die "$signal"; }
Admittedly I had at least 2 issues, one of which was a module croaking on me, which I eval'd as a workaround. Took me a while to find. But the SIGQUIT issue remained.

I got the idea to set up multiple scheduled task service scripts that log what signals they recieve using essentially the same handler as above.

I found that the scheduled tasks configured with the run command as "c:\perl\bin\perl.exe script.pl" were getting the SIGQUIT signals (even at the same time ?!?), while the scipts configured as "E:\SigQUIT_Finder\script.pl" weren't recieving any signals. Who knows why - maybe theres some strange microsoft reason .

hope thats not too much waffle - I wanted to post my results in case any other unfortunate soul runs into the same headaches I did... And if anyone does, feel free to msg me and I'll assist as best I can.

Replies are listed 'Best First'.
Re: Tracing or ignoring SIGQUIT and SIGINT
by cdarke (Prior) on Aug 07, 2009 at 08:31 UTC
    Sorry, but you can't do that on Windows. There is a new(ish) POSIX interface that supports getting the PID of the sender from C, but that is not in the Windows C library so far as I know, and not in Perl.

    The INT signal is generated on Windows by <CTRL>C, QUIT is not supported by the Windows C run-time. Therefore it is being faked by Perl. I don't know which event it is, by my guess would be either <CTRL><BREAK> or <CTRL><CLOSE>. Most likely another process is trying to close down the console session. Without knowing why something is doing that I could not say what the impact of ignoring them would be, but if a process really wants to shut you down then it would do a TerminateProcess(), which is the Win32 API called for SIGKILL. There are dangers with calling SIGKILL, like 3rd party DLLs not being shutdown tidily. SIGTERM, which you can handle from Perl, is probably safer.
Re: Tracing or ignoring SIGQUIT and SIGINT
by Marshall (Canon) on Aug 07, 2009 at 13:43 UTC
    I think you need to figure out where these signals are coming from. You aren't doing it. No other user is doing it. So who else could it be? I suspect that a virus scanner or some sort of "Windows firewall" program (eg, service in Windows world, daemon in Unix world) is figuring out that you are alive and trying to stop you.

    Basically somebody else on this Windows platform is unhappy that you are running and is actively trying to kill you. I found this audio/visual clip on the net and it sounds cool. I watched a bit of it, enough to recommend that you watch it if you don't know about Windows Services. http://www.jasonn.com/turning_off_unnecessary_services_on_windows_xp Basically watch this video to get an idea of how to mess with Window's services, roll in there and turn off everything that you can while still allowing your program to run. Then re-enable things until your program stops.

    But my guess is that one of the anti-virus or firewall things that doesn't know about your program is trying to stop it especially if it is trying to communicate on the web. The number of possibilities is so vast, that I can't offer specifics. But you will have to find that program and then figure out how to get it to "trust you".

    Anyway, the MS OS is not doing this, some other program is. You don't want to ignore these signals (although I can post the code so that you can) because you want to (or should want to) be "well behaved" in the Windows environment.

    Sorry that this doesn't wind up at a thing like: set parmXYZ to 23! You are in for some hacking. I wish you well and I hope I got you started!

Re: Tracing or ignoring SIGQUIT and SIGINT
by desemondo (Hermit) on Aug 17, 2009 at 08:51 UTC
    <please reap>