Ignoring for a moment my general discomfort with the idea of a script installing an application ... I think that this is a good place to use a child-process.   The application forks, then the child execs the installer.   (Or it forks its own child to do so.)   The parent process(es), meanwhile, wait a while.

If they conclude that something is wrong, very careful means must be taken to notify the installer that it must back out, and to wait for it to do so.   You cannot merely kill it, because this might well leave the entire system in an inconsistent state.

Your strategy would “fall dead” if the update required a system restart, as most Windows changes do.

Before pursuing this project very far at all, I would strongly suggest that you do some very diligent research to explore what existing programs might be available that already do this.   Many companies have to “push” system changes out to hundreds of workstations overnight, and there are already many well-developed architectures in place for doing this very thing.   (And if those tools cost money, even a lot of money, “big deal ... do it anyway.”   A trustworthy tool that can actually push mass changes, and can more-or-less guarantee either “clean success” or “no-change failure,” is worth a lot of money.)   This is a high-risk undertaking, and not a trivial one.

Ya im doing it thru a parent and child process only. And regarding system failures and all this is a part of a testing process and the process is being done on vmwares. So not to worry about it. I just need a method in perl to do it..

my $pid;
my $enough = 120;

if ( $pid = fork ) {
    # parent
    sleep $enough;
    unless ( system( "ps -p $pid >/dev/null" ) ) { # 0 exit code means
+ found
        warn "feeling filicidal (plus item description)\n";
        system "kill -9 $pid >/dev/null 2>&1";
    }
}
else { # child
    ... install item ...
    exit;
}
[download]