The long running process dilemma
Recently we had a client on one of our webservers doing something which we consider to be bad form, inconsiderate and downright annoying – running scripts from cron every five minutes which take longer than five minutes to run. The end result? Processes that pile up, consuming resources and frequently inconveniencing other customers (if it is running on a shared webserver).
If the scripts in question are competing for resources, you can frequently end up in a dead-lock or live-lock situation as well. It seems some developers are blissfully unaware of how to write their scripts with enough safety features built in. Fortunately, we at Anchor have encountered these situations enough times to know how to best combat them.
In this scenario our client was using Perl in scripts which measured the response time of remote websites, then logged the data and presented graphs for statistical and trending analysis. OK – this is a wheel that has been reinvented far too many times but that is beside the point. Not only that, but since they were running in series, one slow-responding website in the config file could slow down the entire run and cause the script to take longer than the allotted 5 minutes.
The developer offered to look at the script and improve its efficiency, but we still wanted a failsafe mechanism to stop processes piling up – regardless of the tweaks the developer would make. For this, the Sys::RunAlone Perl module is very handy:
#!/usr/bin/perl import Sys::RunAlone # your code body goes here __END__ # END OF FILE
It’s really that simple. You just need to install the Perl module from CPAN or your method of choice. With the code above in your script, Sys::RunAlone ensures through its locking mechanisms that your script can only ever run a single instance at a time, thus saving webservers everywhere from potential devastation.