What causes "Failed to fully read {0}" in jenkinsci/jenkins?

Check the cause exception (getCause()) for the specific I/O failure type and message.

jenkinsci/jenkins · error · IOException

Failed to fully read {0}

Error message

Failed to fully read {0}

What it means

Wraps any exception (other than NoSuchFileException, which returns an empty string) encountered while reading a log file to a String using a forgiving CharsetDecoder (REPLACE on malformed/unmappable). The file is opened via Files.newInputStream, wrapped in InputStreamReader with the decoder, then BufferedReader, and read with IOUtils.toString.

Source

Thrown at core/src/main/java/hudson/Util.java:279

        // One approach that cannot be used is Files.newBufferedReader, which
        // creates its CharsetDecoder with the default behavior of reporting
        // malformed input and unmappable character errors. The implementation
        // of InputStreamReader(InputStream, Charset) has the desired behavior
        // of replacing malformed input and unmappable character errors, but
        // this implementation is not specified in the API contract. Therefore,
        // we explicitly use a decoder with the desired behavior.
        // See: https://issues.jenkins.io/browse/JENKINS-49060?focusedCommentId=325989&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-325989
        CharsetDecoder decoder = charset.newDecoder()
                .onMalformedInput(CodingErrorAction.REPLACE)
                .onUnmappableCharacter(CodingErrorAction.REPLACE);
        try (InputStream is = Files.newInputStream(Util.fileToPath(logfile));
                Reader isr = new InputStreamReader(is, decoder);
                Reader br = new BufferedReader(isr)) {
            return IOUtils.toString(br);
        } catch (NoSuchFileException e) {
            return "";
        } catch (Exception e) {
            throw new IOException("Failed to fully read " + logfile, e);
        }
    }

    /**
     * Deletes the contents of the given directory (but not the directory itself)
     * recursively.
     * It does not take no for an answer - if necessary, it will have multiple
     * attempts at deleting things.
     *
     * @throws IOException
     *      if the operation fails.
     */
    public static void deleteContentsRecursive(@NonNull File file) throws IOException {
        deleteContentsRecursive(fileToPath(file), PathRemover.PathChecker.ALLOW_ALL);
    }

    /**
     * Deletes the given directory contents (but not the directory itself) recursively using a PathChecker.

View on GitHub (pinned to 2e228ff40b)

Solutions

Check the cause exception (getCause()) for the specific I/O failure type and message.
Verify file permissions: the Jenkins user must have read access to the log file path.
If the path is a symlink, verify the target exists and is readable.
For network filesystems, ensure the mount is healthy and not stale.
If the file is being actively rotated, consider retrying or handling the transient failure.

Defensive patterns

Strategy: try-catch

Validate before calling

// Validate file readability before calling Util.loadLog
if (logfile != null) {
    Path p = Util.fileToPath(logfile);
    if (!Files.isReadable(p)) {
        return ""; // or handle accordingly
    }
}

Try / catch

try {
    String content = Util.loadLogFile(logfile, charset);
} catch (IOException e) {
    // getCause() has the specific failure
    if (e.getCause() instanceof AccessDeniedException) {
        LOGGER.warning("Log file not readable: " + logfile + " — check permissions");
    } else {
        LOGGER.log(Level.WARNING, "Failed to read log file: " + logfile, e);
    }
    return ""; // graceful degradation
}

Prevention

Ensure the Jenkins process user owns or has read access to log file directories.
Avoid symlinks to network filesystems that may become stale.
Use atomic writes or rotation-safe log access patterns to avoid race conditions.

When it happens

Trigger: Any exception in the try-with-resources chain that is not NoSuchFileException — this includes IOException from Files.newInputStream (permission denied, broken symlink), IOException from the Reader, or any other Exception subclass. The original exception is attached as the cause.

Common situations: Log file exists but is not readable due to filesystem permissions (e.g., owned by a different user); file is a broken symlink; disk I/O error or filesystem corruption; file was deleted between the call and the actual open (race condition that slips past NoSuchFileException check); NFS/network filesystem hiccup.

Related errors

AI-assisted analysis of jenkinsci/jenkins@2e228ff40b (2026-08-14). Data as JSON: /api/errors/62593fc1655fa547. Report an issue: GitHub.