[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: prolonged number crunching



On Fri, 7 Dec 2001, Alec wrote:

> On Thursday 06 December 2001 11:41 pm, dman wrote:
> > On Thu, Dec 06, 2001 at 11:21:41PM -0500, Alec wrote:
> > | Hi
> > |
> > | I have a program that produces output to STDOUT and will probably take
> > | several days to run. I already figured that it's better to run it using
> > | "at" utility and collect the results by email. This way the program will
> > | not be bound to any specific terminal and, say crashing X, will not
> > | interrupt it.
> >
> > Why not just
> >
> >     $ the_app > output_file &
> >
> > and then read the file when it is done (or any time in between if you
> > want partial answers or indication of progress)
> 
> the program does not produce much useful output until it's finished. 

Why does this matter? The recommended command does essentially what at
does, without bothering to do the scheduling function, since (based on
your post) you don't need. output_file will contain the program's output,
and you can read it whenever you feel like it.

As others have said, the issue with shutting down seems unimportant --
I've often left my machine running statistical jobs for days at a time
with no problems. Do you anticipate having to shut down?  I suppose you
could go with the signal processing suggestion from before, or (if it's a
recursive problem) spawn individual processes that finish and write
results to disk. But both of these are difficult and messy, far more so
than just leaving the computer on to do its work.


----------------------------------------------------------------------
Andrew J Perrin - andrew_perrin@unc.edu - http://www.unc.edu/~aperrin
 Assistant Professor of Sociology, U of North Carolina, Chapel Hill
      269 Hamilton Hall, CB#3210, Chapel Hill, NC 27599-3210 USA






Reply to: