What causes "wildcard_expandPath: on readdir %s: %s " in apache/hadoop?

Check stability and read permissions of the directory named in the message

wildcard_expandPath: on readdir %s: %s

Error message

wildcard_expandPath: on readdir %s: %s

What it means

While expanding wildcard CLASSPATH entries, wildcard_expandPath scans each directory with opendir/readdir. If errno is non-zero after the scan loop (a readdir failed mid-iteration), it prints 'on readdir <path>: <strerror>' and forces length = -1, failing expansion of that entry and ultimately classpath setup.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-native-client/src/main/native/libhdfs/jni_helper.c:442

                if (expanded != NULL) {
                    // pathLength includes an extra '.'
                    memcpy(dest, path, pathLength - 1);
                    dest += pathLength - 1;
                    memcpy(dest, filename, filenameLength);
                    dest += filenameLength;
                    *dest = PATH_SEPARATOR;
                    dest++;

#ifdef _LIBHDFS_JNI_HELPER_DEBUGGING_ON_
                    printf("wildcard_expandPath:\t%s\t:\t%s\n",
                      filename, expanded);
#endif
                }
            }
        }

        if (errno != 0) {
            fprintf(stderr, "wildcard_expandPath: on readdir %s: %s\n",
              path, strerror(errno));
            length = -1;
        }

        if (closedir(dir) != 0) {
            fprintf(stderr, "wildcard_expandPath: on closedir %s: %s\n",
                    path, strerror(errno));
        }
    } else if ((errno != EACCES) && (errno != ENOENT) && (errno != ENOTDIR)) {
        // can not opendir due to an error we can not handle
        fprintf(stderr, "wildcard_expandPath: on opendir %s: %s\n", path,
                strerror(errno));
        length = -1;
    }

    if (length == 0) {
        // either we failed to open dir due to EACCESS, ENOENT, or ENOTDIR, or
        // we did not find any file that matches *.jar or *.JAR

View on GitHub (pinned to 2add963021)

Solutions

Check stability and read permissions of the directory named in the message
Replace wildcard classpath entries with explicit jar lists (no '*' tokens) so expansion is skipped entirely
Raise fd limits (ulimit -n) if the underlying error is EMFILE

Example fix

# before
export CLASSPATH="/opt/hadoop/share/hadoop/common/*"

# after (pre-expanded, no directory scan)
export CLASSPATH="$(/opt/hadoop/bin/hadoop classpath --glob)"

Defensive patterns

Strategy: fallback

Validate before calling

/* preflight each wildcard directory before JVM init */
static int dir_scannable(const char *dir) {
    DIR *d = opendir(dir);
    if (!d) return 0;
    struct dirent *e;
    while ((e = readdir(d)) != NULL) { /* touch entries */ }
    int failed = (e == NULL && errno != 0);
    closedir(d);
    return !failed;
}

Try / catch

/* shell-level: sidestep the scan entirely when directory access is unreliable */
# export CLASSPATH="$(hadoop classpath --glob)"

Prevention

Prefer pre-expanded CLASSPATHs over wildcard entries
Keep classpath directories stable and locally mounted
Watch fd usage (ulimit -n) in processes with big classpaths

When it happens

Trigger: Directory contents or permissions changing while the directory is being scanned; NFS/network-mounted classpath directories returning transient errors; EMFILE from running out of file descriptors during the scan.

Common situations: Wildcard classpath entries over shared or network mounts; concurrent jar upgrades writing into the same Hadoop install tree; long-running processes with fd leaks.

Related errors

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