[CentOS] Consecutive Jobs

Thu Apr 8 12:34:18 UTC 2010
Les Mikesell <lesmikesell at gmail.com>

JohnS wrote:
> On Wed, 2010-04-07 at 07:33 -0500, Les Mikesell wrote:
>> Joseph L. Casale wrote:
>>>> Are you looking for a real job scheduler?  If so, it might be overkill,
>>>> but you might want to look into software like Sun Grid Engine, Torque,
>>>> or Condor (there are quite a few other schedulers out there).  If those
>>>> aren't what you're hoping for, perhaps you could give more details about
>>>> what you're trying to accomplish.
>>> Based on John and Les's reco for a different cluster need, I am reading up
>>> on Torque etc now, but this just a trivial need I want to plug asap. It really
>>> is as simple as I wrote out earlier, multiple servers ssh a background job at
>>> nearly the same time consisting of an rsync command. The destination host for
>>> this target gets overwhelmed with more than one at a time...
>> If you don't mind introducing a single point of failure, pick a control host and 
>> ssh all the commands in a shell script that loops over the list of targets to 
>> run it.
> ---
> And yes that it what I shared that I currently do in the previous
> thread.  BUT I do not use ssh_cluster now.  Actually the one controler
> host is 999.999 up time at presant IBM AIX knock on wood.  My next thing
> is to do job ques through the mrg platform utilizing the python modules
> on 2 machines and dump cosly AIX.

A very long time ago I did some generic job queueing stuff by hooking scripts 
into the unix lpr print spooler which had the advantage that they could be 
submitted from windows boxes through samba by going through the motions of 
printing them, but things have changed quite a bit since then and I don't know 
if that would still be easy.  If the commands are always the same or the 
variable parts can be read as a list from a file, a shell loop is probably the 
easiest approach.  You can also make a shell script read from a named pipe which 
will wait for something to be written, but you have to be careful about the size 
of the writes if there are concurrent writers to keep them from being interleaved.

   Les Mikesell
    lesmikesell at gmail.com