Re: What to do if $TMPDIR runs full?

[Andrew Clegg]

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 <andrew.clegg+parallel@gmail.com> 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.
>
>
>