Beefy Boxes and Bandwidth Generously Provided by pair Networks
Think about Loose Coupling
 
PerlMonks  

Kill a process in perl windows and proceed only if it killed the process

by Anonymous Monk
on Jul 19, 2012 at 21:35 UTC ( #982720=perlquestion: print w/ replies, xml ) Need Help??
Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Hello-

I would like to kill a processid in perl and I want to verify whether it actually killed the process. If it fails I need to try it again one more time otherwise exist.
Is Win32::Process::KillProcess is the best method to kill a process in perl for an application running on windows environment?
Will KillProcess return true on success?
what this exit code means will that tells me it was a success?
How can I check with an exitcode or returnCode and make sure a process acually killed?
should I call TRYAGAIN: my $exitcode = 0; my $count = 0; Win32::Process::KillProcess($pid, $exitcode); # is the method just issue the kill command here and moving # or is it + really waits until the process gets killed? if ($exitCode != 1) { # is this a right check? ++$count; if ($count == 2) { print "Error: Failed Killing: " . $pid; exit; } goto TRYAGAIN }

Comment on Kill a process in perl windows and proceed only if it killed the process
Download Code
Re: Kill a process in perl windows and proceed only if it killed the process
by GrandFather (Cardinal) on Jul 19, 2012 at 22:11 UTC

    Often it's not enough to kill a process, you need to kill a process tree. For example modern compilers often spawn additional processes to manage various parts of the compile and link processing. Another part of the problem can be that some processes may take a long time to close down or even may be prevented from closing due to things like dialogues that need to be closed. The following sub may help with the process tree part of the problem, but doesn't address the UI problem at all:

    sub KillProcTree { my ($pid) = @_; if ($^O ne 'MSWin32') { return "Aborting" if !$pid || !kill 'HUP', $pid; return "Aborted"; } require 'Win32/Process/Info.pm'; require 'Win32/Process.pm'; Win32::Process::Info->import(); my $pi = Win32::Process::Info->new('', 'WMI'); my $iters; while (my %info = $pi->Subprocesses($pid)) { if (++$iters > 40) { Win32::Process::KillProcess($pid, -1); return 'Aborting'; } my @leaves = grep {!@{$info{$_}}} keys %info; last if !@leaves; print "Killing: @leaves\n"; Win32::Process::KillProcess($_, -1) for @leaves; sleep 2; # Allow a little time for processes to die } return 'Aborted'; }
    True laziness is hard work
Re: Kill a process in perl windows and proceed only if it killed the process
by linuxkid (Sexton) on Jul 19, 2012 at 22:19 UTC

    Read. The. Docs.

    --linuxkid


    imrunningoutofideas.co.cc
Re: Kill a process in perl windows and proceed only if it killed the process
by BrowserUk (Pope) on Jul 19, 2012 at 22:53 UTC
    Will KillProcess return true on success? what this exit code means will that tells me it was a success? How can I check with an exitcode or returnCode and make sure a process actually killed?
    • If KillProcess() returns non-zero; the process *will* terminate.

      The process cannot prevent it.

    • If it returns zero; it probably means you do not have the privileged to kill it.

      Check $^E for the reason it failed.

    • The exitcode parameter to KillProcess() is an input parameter; not an output parameter.

      It is the value that will be returned to any process that calls GetExitProcess() after it has been killed.

    • If you absolutely need to know that the process is dead; as opposed to knowing that it will die at some point in the near future:

      Follow the KillProcess() call with a call to the Wait() method.

      When that returns the process is actually dead,

    • As stated above, if KillProcess() returns true, the process *will die*; but if you need to know if it was you that killed it:

      Pass an unusual exitcode (eg. not 1 or 0 or -1; say 13579 or your favorite sub 2**16 prime number).

      And then call the GetExitCode() method and compare. Not that you would be able to do anything about it if it wasn't.

    There is absolutely no reason to loop!

    If you have the appropriate permissions to kill the process; the single call to KillProcess() will kill it. And if you do not; retrying won't help.

    Calling the Wait() method will ensure that it has actually died before your program continues; but be aware that if -- for example -- the process had just initiated a synchronous read request -- say a blocking tcp read -- to device or server that was slow, broken or non-existent, then you might have to wait quite some time before the process actually goes away and the Wait() completes. (For example: many tcp timeouts default to 900 seconds; some default DB server timeouts are even longer!)

    The bottom line is: for most purposes, simply getting a non-zero return code from KillProcess() is enough to allow you to proceed.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

    The start of some sanity?

      I tried the killProcess call followed by wait() call that BrowserUK suggested, but when I tried Win32::Process::Wait it gives me this error message- 'Usage:Win32::Process::Wait(cP, timeout)'
      what is 'cP' argument means?
      $^E=0; Win32::Process::KillProcess($pid, 111) or warn $^E; Win32::Process::Wait(INFINITE);
      Thanks,
      Peter
        what is 'cP' argument means?

        You are calling Win32::Process::Wait() as a subroutine; you should be calling it as a method.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.

        The start of some sanity?

Re: Kill a process in perl windows and proceed only if it killed the process
by Anonymous Monk on Jul 20, 2012 at 02:18 UTC
    In the general case, killing a process is an asynchronous event ... it can take an arbitrary amount of time, especially if there are interactive dialog-boxes involved, and this can pragmatically result in situations like deadlock; or even actual deadlock of the user-interface. So, fire the bullet but don't wait for the body to hit the floor. Emphatically don't wait...

      will system(kill -9 <pid>) not work here ? I am just curious...

        Not on Windows. And if you are on a POSIX system, why shell out instead of using the built-in kill?
        Indeed, on Linux I myself prefer system(shutdown -r now).
        --
        if ( 1 ) { $postman->ring() for (1..2); }
Re: Kill a process in perl windows and proceed only if it killed the process
by sundialsvc4 (Abbot) on Jul 20, 2012 at 14:44 UTC

    When you “kill” a process, on any operating system at all, you are unconditionally forcing it into its exit-path.   Your request may be refused:   you might not be authorized to kill the process.   In any case, the process might have to do an arbitrary number of things in order to finish dying, and it might be delayed for any number of reasons.   Some of those reasons might involve resources that you directly or indirectly hold.   The process, if it interacts at all with the user interface, will need to change that interface and that can involve grabbing and releasing all kinds of shared locks within the window system.   Figurative and literal deadlocks can occur very easily.

    If you kill the process, don’t expect to be able to collect any sort of completion-status from it.   If you need to wait until after the process has died, set up some kind of timed-wait loop to poll the process-id until the OS says the process doesn’t exist.   But, be sure that the loop will end after a finite amount of time.   (When you get confirmation that the PID is gone, wait one more time... just in case.)   I make these suggestions, not because there are not other ways to do it (operating system dependent ...), but because this strategy keeps the assassin and his prey at arms length from each other, and not dependent for correct operation upon any uncertainties of the outcome.   There are many timing potholes on this road.

    Also:   if you want a process to die, and that process belongs to you, design the process in such a way that it will accept some kind of a signal from you that it should please at once terminate itself.   The process should in a good and graceful manner put its affairs in order and, immediately prior to jumping on its own steam into the Great Beyond, transmit a final farewell back to you.   Consider also, in that case, whether it is possible and perhaps better for the signal to mean, “immediately quit what you are doing, signal back that you have done so, and then wait ... still very much alive ... for your next instructions.”   Even better, let the program set its own timer or what-have-you and to discover for itself, with no external prompting, that it cannot complete the unit of work that it set out to do.   Pointing a loaded pistol at a process’s head and pulling the trigger quite without warning, while it may be “effective,” is hardly elegant, and therefore frequently troublesome.   If possible, FABWTDI = Find A Better Way To Do It.

      When you “kill” a process, on any operating system at all, you are unconditionally forcing it into its exit-path.

      No. You are not! You are so wrong here it isn't even funny.

      Why do you do this?

      Why do you spout such crap, at such length on subjects that you obviously have not the vaguest clue about?


      With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
      Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
      "Science is about questioning the status quo. Questioning authority".
      In the absence of evidence, opinion is indistinguishable from prejudice.

      The start of some sanity?

        Sundial is somewhat correct. On all OSes, there are voluntary closes, and forced closes. On unix there are different signals and different kill -* numbers. On Windows there is WM_CLOSE message, or SetConsoleCtrlHandler (which under the hood is a csrss.exe getting a WM_CLOSE or a control C message), these 2 are voluntary. Then there is TerminateProcess which is forced.

        TerminateProcess I know is privilage checked (not sure about how windows messages work). Also on NT Kernel, if a process did certain syscalls, (my specific experience is with NtCreateFile/CreateFile), a driver can freeze a thread, and absolutely nothing can terminate that process since NT Kernel runs a kernel mode APC (think unix signal) in each thread to terminate each thread and the process/PID disappears when the last thread is removed from the process, but the thread is stuck in a blocking synchronous IO call in a driver, the kernel can not preempt most kernel mode code (google IRQL) executing in a thread to schedule an APC. Basically, CreateFile is synchronous, the path driver UNC/My Network Places driver which implements "\\1.2.3.4\someshare" paths on NT is crap. This driver is called MUP, which is one of many MS schemes at user mode drivers. MUP connects to Workstation/COmputer Browser services, which does the actual socket IO from user mode. Why? Either MS decided kernel socket interface in the kernel is so difficult to use, or MS's My Network Places/Samba/CIFS implementation still uses DOS/16 bit code that was ported to 32 bits, but still has to be run in user mode. NT 6/Vista introduced a a couple new calls to cancel sync I/O in any thread from any thread, so perhaps this unterminatable process problems doesn't exist anymore in NT 6. When Explorer freezes for many seconds or file open freezes for many seconds when browsing network shares, blame CreateFile and MUP.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://982720]
Approved by GrandFather
Front-paged by cavac
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others having an uproarious good time at the Monastery: (9)
As of 2014-12-19 20:37 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (91 votes), past polls