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

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

Hello dear Monks,

I tried all %SIG's :

... $SIG{HUP} = sub { print "You cannot HUP me !"; }; $SIG{ILL} = sub { print "You cannot ILL me !"; }; $SIG{INT} = sub { print "You cannot INT me !"; }; ... while (1) { print "\nyes"; sleep (1); }

Complete code here.

This works with ctrl+c (it prints 'You cannot INT me !' and goes on).
But when I close cmd.exe, it prints 'You cannot HUP me !' and die.

Any idea ?

Thanks.

Have a nice day.

"There is only one good, namely knowledge, and only one evil, namely ignorance." Socrates

Replies are listed 'Best First'.
Re: It is possible to prevent cmd.exe from being killed ?
by Old_Gray_Bear (Bishop) on Nov 30, 2005 at 20:56 UTC
    Just a guess, but I'd bet that the SIGHUP is sent as part of the System shut-down process.

    Note: SIGKILL is not really stopable; you can catch a KILL and stick code in the subroutine to do cleanup (close files, delete semaphores, and such), but once your routine is finished, the System will continue shutting down your process. Kill is the equivilent of the 'Non-Maskable Interupt' that the hardware uses to inform you that "A Serious Error Has Occured, and I Am Leaving Now". (Often followed by an unsuccessful attempt to dump core.)

    ----
    I Go Back to Sleep, Now.

    OGB

Re: It is possible to prevent cmd.exe from being killed ?
by BrowserUk (Patriarch) on Nov 30, 2005 at 21:13 UTC

    It isn't cmd.exe you need to prevent from being terminated, but perl.exe that is running your script. The reason your script dies when the user closes the console window, is because perl.exe is being run as a child of cmd.exe which created that console and when you kill a process with children, they die also.

    There are various things you can do to address that. Which is applicable depends upon whether the program you are trying to prevent from being killed needs to be able to communicate with the user, and if it does, is it a console app, or a gui app of some form.

    But ultimately, why are you trying to stop the user from stopping this program from running?

    If it is some corporate policy that dictates this for users of it's corporate network, then whilst I think it is a wrong policy, there are ways that administrators can define policies that will prevent non-administrative users from terminating programs started by administrators. And most large corporations, which is where this kind of big-brother think is prevelant, will have people who know how to do this, or the support contacts through which they can find out.

    For any other purpose, particularly if it is of the type "my program is obviously more important than anything else the user might be running", then you should probably think again anyway.


    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      Hello Monks,

      The script performs remote integrity checks each x hours.
      So it should be run on a dedicated box by people who know what they do.
      It shouldn't be a problem. It's more curiosity.

      It's a console app, sometimes (report mode) it has to print to STDOUT, and in 'monitor mode' it needs no communication.

      Thanks for your answers.

      Have a nice day.

      "There is only one good, namely knowledge, and only one evil, namely ignorance." Socrates