apache/cassandra · error · RuntimeException
Couldn't read from temporary stress log file
Error message
Couldn't read from temporary stress log file
What it means
StressGraph.parseLogStats reads the temporary stress log line by line while building graph stats; any IOException during reading is rethrown as RuntimeException 'Couldn't read from temporary stress log file'. The cause is discarded, so the real read failure (file vanished, closed handle, permissions) is invisible. It is thrown after the parsing loop, meaning the log became unreadable partway through.
Solutions
- Rerun the stress/graph operation ensuring the temporary log file is not deleted or cleaned during the run.
- Point temp storage at a stable directory (not aggressive tmp-cleanup locations) with sufficient space.
- Avoid running concurrent stress graph jobs sharing the same temporary log path.
- Patch the catch to chain the cause: new RuntimeException("Couldn't read from temporary stress log file", e).
Example fix
// before
catch (IOException e)
{
throw new RuntimeException("Couldn't read from temporary stress log file");
}
// after
catch (IOException e)
{
throw new RuntimeException("Couldn't read from temporary stress log file", e);
} Defensive patterns
Strategy: retry
Validate before calling
java.io.File tmp = logFile; if (tmp != null && !tmp.canRead()) throw new IllegalStateException("Temporary stress log unreadable before parsing: " + tmp); Try / catch
try { graph.generate(); } catch (RuntimeException e) { if (e.getMessage().contains("Couldn't read from temporary stress log")) System.err.println("Temp log lost; rerun stress with graphing enabled and disable /tmp cleaners"); throw e; } Prevention
- Disable aggressive /tmp cleanup (tmpwatch/systemd-tmpfiles) during long stress runs.
- Use unique temp paths per concurrent stress job.
- Keep temp storage on reliable, adequately sized filesystems.
When it happens
Trigger: createJSONStats -> parseLogStats reads the temporary log produced during the stress run; the temp file is deleted concurrently (cleanup, tmpwatch), is on a full/failed filesystem, or the stream errors mid-read.
Common situations: Long stress graphing runs while /tmp cleanup removes the temporary log; multiple stress instances clobbering each other's temp files; container tmpfs limits; disk errors.
Understand the failure class
Background: "failed to read file", EACCES, ENOENT and "could not read <path>" errors: when a program can't read a file from disk — this error's family across 49 libraries.
Related errors
- Couldn't load existing stats html.
- Attempted skipBytes() on a closed RAR
- Attempted to seek in a closed RAR
- Ballot file corrupted
- Can't open %r for reading
AI-assisted analysis of apache/cassandra@88fd0f6a0e (2026-09-10).
Data as JSON: /api/errors/f71c8e89fc20810c.
Report an issue: GitHub.
Appendix: source
Thrown at tools/stress/src/org/apache/cassandra/stress/StressGraph.java:234
if (currentThreadCount == null)
json.put("revision", stressSettings.graph.revision);
else
json.put("revision", String.format("%s - %s threads", stressSettings.graph.revision, currentThreadCount));
String command = StringUtils.join(stressArguments, " ").replaceAll("password=.*? ", "password=******* ");
json.put("command", command);
json.set("intervals", intervals);
stats.add(json);
//Start fresh for next iteration:
json = JsonUtils.JSON_OBJECT_MAPPER.createObjectNode();
intervals = JsonUtils.JSON_OBJECT_MAPPER.createArrayNode();
mode = ReadingMode.START;
}
}
}
catch (IOException e)
{
throw new RuntimeException("Couldn't read from temporary stress log file");
}
if (json.size() != 0) stats.add(json);
return stats;
}
private ObjectNode createJSONStats(ObjectNode json)
{
try (InputStream logStream = Files.newInputStream(stressSettings.graph.temporaryLogFile.toPath()))
{
ArrayNode stats;
if (json == null)
{
json = JsonUtils.JSON_OBJECT_MAPPER.createObjectNode();
stats = JsonUtils.JSON_OBJECT_MAPPER.createArrayNode();
}
else
{
stats = (ArrayNode) json.get("stats");View on GitHub (pinned to 88fd0f6a0e)