Alternatively, maybe some sort of a --fail-fast flag, which will cause the whole thing to abort (with a message to stderr) if one of the jobs returns non-zero?
This might be generally useful for long-running jobs, especially in the cases like this where it's a common failure mode that would mean you need to restart them all anyway. On 2 December 2013 11:01, Andrew Clegg <[email protected]> wrote: > Ole Tange <tange <at> gnu.org> writes: > >> Maybe it would be possible to append a byte to the tmp files before >> printing them. If ftell stays the same then the append did not work >> and a warning should be written. If it worked, seek back 1 byte and >> truncate. This, however, might slow down printing of a job, and seems >> like a lot of checking to do for each and every job for the off chance >> that $TMPDIR is full. > > Hi, > > I'm the guy who originally raised #40733 on this subject. > > I would tend to agree that this might not be the most robust way of doing > this. > I guess there could be other situations where writing would fail during the > actual job execution, but work during output preparation -- e.g. too many open > files during execution. > > Would it be better to keep track (in memory) of the return codes from the > individual jobs, and if any are non-zero, print a warning to stderr along with > a summary of the failed ones? > > Something like: > > Warning: 3 jobs returned non-zero exit status > zcat 2013-01-01-01.gz returned 1 > zcat 2013-01-01-02.gz returned 1 > zcat 2013-01-01-03.gz returned 1 > > Possibly with a flag to suppress this output, or log it instead of printing it > -- just in case (a) you are expecting non-zero status and (b) you need the > contents of stderr unmodified for further processing. > > Andrew. > > >
