apache/hadoop · error

error:

Error message

 error:

What it means

This is the banner printExceptionAndFreeV writes right after the caller-supplied context string (e.g. "hdfsOpenFile(/path): FileSystem#create") whenever a Java exception from a libhdfs JNI call is being reported. Seeing it means the underlying Hadoop operation genuinely threw; the ExceptionUtils root-cause message and stack trace follow on the next lines, and the function returns an errno mapped from the exception class via gExceptionInfo (FileNotFoundException->ENOENT, AccessControlException->EACCES, SafeModeException->EROFS, QuotaExceededException->EDQUOT, unknown->EINTERNAL).

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfs/exception.c:187

    }
    if (i < EXCEPTION_INFO_LEN) {
        noPrint = (gExceptionInfo[i].noPrintFlag & noPrintFlags);
        excErrno = gExceptionInfo[i].excErrno;
    } else {
        noPrint = 0;
        excErrno = EINTERNAL;
    }

    // We don't want to use ExceptionDescribe here, because that requires a
    // pending exception. Instead, use ExceptionUtils.
    rootCause = getExceptionUtilString(env, exc, "getRootCauseMessage");
    stackTrace = getExceptionUtilString(env, exc, "getStackTrace");
    // Save the exception details in the thread-local state.
    setTLSExceptionStrings(rootCause, stackTrace);

    if (!noPrint) {
        vfprintf(stderr, fmt, ap);
        fprintf(stderr, " error:\n");

        if (!rootCause) {
            fprintf(stderr, "(unable to get root cause for %s)\n", className);
        } else {
            fprintf(stderr, "%s", rootCause);
        }
        if (!stackTrace) {
            fprintf(stderr, "(unable to get stack trace for %s)\n", className);
        } else {
            fprintf(stderr, "%s", stackTrace);
        }
    }

    destroyLocalReference(env, exc);
    free(className);
    return excErrno;
}

View on GitHub (pinned to 2add963021)

Solutions

  1. Read the lines that follow this banner - they contain the ExceptionUtils root cause and stack trace identifying the actual Hadoop-side failure.
  2. Map the returned errno via the gExceptionInfo table to decide handling (ENOENT missing path, EACCES permissions, EROFS safe mode, EDQUOT quota, EEXIST duplicate, ESTALE lease).
  3. Fix the named Hadoop-side condition (path, permissions, quota, safe mode) rather than changing C-side code.
  4. In fuse-dfs contexts, also check the HDFS audit log for the corresponding denied/failed operation.
Defensive patterns

Strategy: try-catch

Try / catch

hdfsFile f = hdfsOpenFile(fs, path, O_WRONLY | O_CREAT, 0, 0, 0);
if (!f) {
    int e = errno;  /* libhdfs already mapped the Java exception class */
    const char *rc = hdfsGetLastExceptionRootCause();
    switch (e) {
    case ENOENT:  /* FileNotFoundException: parent missing */ break;
    case EACCES:  /* AccessControlException */ break;
    case EROFS:   /* SafeModeException */ break;
    case EDQUOT:  /* QuotaExceededException */ break;
    case EEXIST:  /* FileAlreadyExistsException */ break;
    default:      /* see stderr banner + stack trace for the rest */ break;
    }
}

Prevention

When it happens

Trigger: Any hdfs* API whose internal JNI call throws and whose exception class is not suppressed by the noPrintFlags: hdfsOpenFile on a missing parent directory, hdfsRename without permission, hdfsDelete/hdfsCreate while the NameNode is in safe mode, quota exceeded on write, file already exists, etc.

Common situations: Standard companion of every printed libhdfs failure in application stderr and fuse-dfs logs; developers grepping logs find the fragment '<operation> error:' followed by the Java stack trace.

Related errors


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