Re^2: Kill process after X mins

Many thanks, Corion!

alarm does exactly what I was looking for. Does it also work if the process hung? In my case, it's a "while" loop and it was killed at the specified time.

I'm using a shared server and don't have control over (1) and (3).

Comment on Re^2: Kill process after X mins

Replies are listed 'Best First'.
Re^3: Kill process after X mins by Corion (Patriarch) on Jul 21, 2011 at 13:21 UTC
alarm is likely a feature supplied by your operating system, so whether alarm works for a "hung" process really depends on your operating system and what you consider "hung". On unixish operating systems, SIGALRM will interrupt almost any (system) call. Most recent versions of Perl will likely only process signals after system calls have returned ("safe signals"). If your program gets "hung" in an endless loop, the SIGALRM handler will stop your program. If your program gets "hung" in some system call, it will not necessarily get immediately stopped. Personally, I question the wisdom of the person administrating the "shared server" without hard ulimits and hard maximum request limits, but maybe they have reasons for not limiting the resources users can consume.	[reply]

Replies are listed 'Best First'.

Re^3: Kill process after X mins
by Corion (Patriarch) on Jul 21, 2011 at 13:21 UTC

alarm is likely a feature supplied by your operating system, so whether alarm works for a "hung" process really depends on your operating system and what you consider "hung".

On unixish operating systems, SIGALRM will interrupt almost any (system) call. Most recent versions of Perl will likely only process signals after system calls have returned ("safe signals"). If your program gets "hung" in an endless loop, the SIGALRM handler will stop your program. If your program gets "hung" in some system call, it will not necessarily get immediately stopped.

Personally, I question the wisdom of the person administrating the "shared server" without hard ulimits and hard maximum request limits, but maybe they have reasons for not limiting the resources users can consume.

[reply]