parallel
[Top][All Lists]
Advanced

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

Re: What to do if $TMPDIR runs full?


From: Andrew Clegg
Subject: Re: What to do if $TMPDIR runs full?
Date: Mon, 2 Dec 2013 11:01:20 +0000 (UTC)
User-agent: Loom/3.14 (http://gmane.org/)

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]