From mboxrd@z Thu Jan 1 00:00:00 1970 From: urgrue Subject: Re: a command "spool", ie queueing commands? Date: Thu, 04 Aug 2005 07:26:08 +0000 Message-ID: <1123140368l.3265l.0l@hyttynen> References: <1122963263l.32575l.0l@hyttynen> <60a7468905080200315678d209@mail.gmail.com> <1122969644l.1939l.0l@hyttynen> <20050804005710.GA16052@open-core.com.ar> Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Return-path: In-Reply-To: <20050804005710.GA16052@open-core.com.ar> (from ecastag@fi.uba.ar on Thu Aug 4 03:57:10 2005) Content-Disposition: inline Sender: linux-admin-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="us-ascii"; delsp="Yes"; format="Flowed" To: linux-admin@vger.kernel.org On 08/04/2005 03:57:10 AM, Emiliano Castagnari wrote: > You could try something like: > > $ command1 && command2 && command3 Better would be command1 ; command2 ; command3, because then it won't depend on the previous command coming out true. But nevertheless it lacks the ability for me to add and remove commands from the queue after it's started, which is almost the main feature that I need. Basically it would be good enough if "at" could do "at -next", which would run the job after any that were already running completed. The "batch" command is good but bases whether or not to do a job on cpu load levels, whereas I'm looking for the same but for disk load levels. > Another way, is to simply develop it ... it doesn't seem like a very > hard one to code :) This may be true. It might be easiest to do it as an addition to "at", since all the spooling logic and daemon is already there.... I can't code worth a damn, but maybe I could swing altering "batch" to monitor disk load levels instead...if only there was a general disk load monitor that was as reliable as loadavg... Or perhaps "at -next" would be easier. Instead of looking at the time, look if a job is running - if one is, postpone the job by a few minutes.