apache/hadoop · info · RequestStopException

user requested stop

Error message

user requested stop

What it means

MetaRecoveryContext.prompt drives the interactive prompts of 'hdfs namenode -recover' over a damaged edit log; answering 's' (stop reading the edit log here, abandoning any later edits) throws RequestStopException with message 'user requested stop'. This is deliberate control flow, not a malfunction: callers such as the edit-log replay loop catch it to finish recovery cleanly at the chosen transaction. The image will simply end at that txid.

Source

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

        MetaRecoveryContext recovery, String contStr)
        throws IOException, RequestStopException
  {
    if (recovery == null) {
      throw new IOException(prompt);
    }
    LOG.error(prompt);
    String answer = recovery.ask("\nEnter 'c' to continue, " + contStr + "\n" +
      "Enter 's' to stop reading the edit log here, abandoning any later " +
        "edits\n" +
      "Enter 'q' to quit without saving\n" +
      "Enter 'a' to always select the first choice in the future " +
      "without prompting. " + 
      "(c/s/q/a)\n", "c", "s", "q", "a");
    if (answer.equals("c")) {
      LOG.info("Continuing");
      return;
    } else if (answer.equals("s")) {
      throw new RequestStopException("user requested stop");
    } else if (answer.equals("q")) {
      recovery.quit();
    } else {
      recovery.setForce(FORCE_FIRST_CHOICE);
      return;
    }
  }

  /** Log a message and quit */
  public void quit() {
    LOG.error("Exiting on user request.");
    System.exit(0);
  }

  public int getForce() {
    return this.force;
  }

View on GitHub (pinned to 2add963021)

Solutions

1. If stopping was intended, nothing to fix: restart the NN and accept that transactions after the stop point are gone.
2. To keep later edits, re-run recovery and answer 'c' (continue) or 'a' (always first choice) instead.
3. If the corruption was only a bad segment tail, restore the later segments from JournalNodes or backups first, then re-run recovery past the stop point.

long lastApplied = imageTxid;
try {
  loader.loadFetchedEdits(...); // replay loop honoring MetaRecoveryContext prompts
} catch (MetaRecoveryContext.RequestStopException stop) {
  // operator chose to abandon later edits - persist cleanly at the stop point
  LOG.warn("Edit replay stopped by operator at txid {}", lastApplied);
  saveNamespaceAt(lastApplied);
}

When it happens

Trigger: An operator (or a script feeding stdin) runs 'hdfs namenode -recover' on a corrupted edit log, hits a corrupt-record prompt, and answers 's' to abandon all later edits.

Common situations: Operators deliberately truncating replay before a known-bad region; scripted recovery sessions piping 's'; operators surprised afterwards that writes after the stop txid are missing from the recovered namespace.

Related errors

• No edits file for txid " + startTxId + "-" + endTxId + " exi
• Can't combine -recover with other startup options.
• Error parsing recovery options: can't understand option "{ar
• Illegal option {}
• Not enough arguments: expected {} but got {}

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