apache/hadoop · error · LogHeaderCorruptException

Reached EOF when reading log header

Error message

Reached EOF when reading log header

What it means

LogHeaderCorruptException('Reached EOF when reading log header') raised inside EditLogFileInputStream.readLogVersion(): the initial in.readInt() for the layout version hit EOF, i.e., the file ended before the 4-byte version could be read. This is the same 'empty/truncated before the header' condition as the caller-side check, surfaced on code paths that call readLogVersion directly (validation of candidate logs, offline tooling).

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs/src/main/java/org/apache/hadoop/hdfs/server/namenode/EditLogFileInputStream.java:382

    } finally {
      IOUtils.closeStream(in);
    }
  }

  /**
   * Read the header of fsedit log
   * @param in fsedit stream
   * @return the edit log version number
   * @throws IOException if error occurs
   */
  @VisibleForTesting
  static int readLogVersion(DataInputStream in, boolean verifyLayoutVersion)
      throws IOException, LogHeaderCorruptException {
    int logVersion;
    try {
      logVersion = in.readInt();
    } catch (EOFException eofe) {
      throw new LogHeaderCorruptException(
          "Reached EOF when reading log header");
    }
    if (verifyLayoutVersion &&
        (logVersion < HdfsServerConstants.NAMENODE_LAYOUT_VERSION || // future version
         logVersion > Storage.LAST_UPGRADABLE_LAYOUT_VERSION)) { // unsupported
      throw new LogHeaderCorruptException(
          "Unexpected version of the file system log file: "
          + logVersion + ". Current version = "
          + HdfsServerConstants.NAMENODE_LAYOUT_VERSION + ".");
    }
    return logVersion;
  }
  
  /**
   * Exception indicating that the header of an edits log file is
   * corrupted. This can be because the header is not present,
   * or because the header data is invalid (eg claims to be
   * over a newer version than the running NameNode)

View on GitHub (pinned to 2add963021)

Solutions

1. Run hdfs namenode -recover to sideline the corrupt segment (it holds no readable transactions).
2. Use offlineEditsViewer with the -r (recover) flag to inspect what is salvageable: hadoop org.apache.hadoop.hdfs.tools.offlineEditsViewer.OfflineEditsViewer -r -i edits_* -o /tmp/out.xml.
3. Restore missing journal range from an HA peer (bootstrapStandby) or checkpoint backup if transactions were actually lost.

Example fix

# before: 'Reached EOF when reading log header' during edits validation
hadoop org.apache.hadoop.hdfs.tools.offlineEditsViewer.OfflineEditsViewer \
  -r -i edits_in_progress_0000000000020000 -o /tmp/check.xml
# after: confirms the segment is empty; discard it and restart the NameNode

if (Files.size(editsFile) < 4) {
  // cannot even hold the layout-version int: every reader will fail with a header exception
}

static boolean isCorruptLogHeader(IOException e) {
  return e instanceof EditLogFileInputStream.LogHeaderCorruptException;
}

try {
  int v = EditLogFileInputStream.readLogVersion(in, true);
} catch (EditLogFileInputStream.LogHeaderCorruptException e) {
  // empty/sub-4-byte log: no transactions; drop it and move to the previous segment
}

When it happens

Trigger: Any consumer calling readLogVersion on an edits file with fewer than 4 bytes: zero-length segment, or a file whose first 4 bytes were never flushed; exercised by validateLog, FSEditLogLoader startup replay and offlineEditsViewer -r recovery mode.

Common situations: Crash or disk-full during segment creation; truncated journal file copies; name-dir restored from an incomplete backup.

Related errors

• No header found in log
• EOF while reading layout flags from log
• The log file {} seems to contain valid transactions ; journa
• Same delegation token being added twice; invalid entry in fs
• No header present in log (value is -1), probably due to disk

AI-assisted analysis of apache/hadoop@2add963021 (2026-08-22). Data as JSON: /api/errors/d6929891bb3e09c4. Report an issue: GitHub.