apache/hadoop · critical · ServerException

S03

S03

Error message

Could not load file from classpath [{0}], {1}

What it means

When no <name>-log4j.properties file exists in the config dir, Server.initLog() falls back to loading the bundled default log4j resource from the classpath; if that InputStream load throws IOException, init throws ServerException S03('Could not load file from classpath [httpfs-log4j.properties], <cause>'). This indicates a broken deployment rather than a configuration choice.

Source

Thrown at hadoop-hdfs-project/hadoop-hdfs-httpfs/src/main/java/org/apache/hadoop/lib/server/Server.java:429

   */
  protected void initLog() throws ServerException {
    verifyDir(logDir);
    LogManager.resetConfiguration();
    File log4jFile = new File(configDir, name + "-log4j.properties");
    if (log4jFile.exists()) {
      PropertyConfigurator.configureAndWatch(log4jFile.toString(), 10 * 1000); //every 10 secs
      log = LoggerFactory.getLogger(Server.class);
    } else {
      Properties props = new Properties();
      try {
        InputStream is = getResource(DEFAULT_LOG4J_PROPERTIES);
        try {
          props.load(is);
        } finally {
          is.close();
        }
      } catch (IOException ex) {
        throw new ServerException(ServerException.ERROR.S03, DEFAULT_LOG4J_PROPERTIES, ex.getMessage(), ex);
      }
      PropertyConfigurator.configure(props);
      log = LoggerFactory.getLogger(Server.class);
      log.warn("Log4j [{}] configuration file not found, using default configuration from classpath", log4jFile);
    }
  }

  /**
   * Loads and inializes the server configuration.
   *
   * @throws ServerException thrown if the configuration could not be loaded/initialized.
   */
  protected void initConfig() throws ServerException {
    verifyDir(configDir);
    File file = new File(configDir);
    Configuration defaultConf;
    String defaultConfig = name + "-default.xml";
    ClassLoader classLoader = Thread.currentThread().getContextClassLoader();

View on GitHub (pinned to 2add963021)

Solutions

1. Verify and redeploy the distribution: compare checksums of the httpfs/hadoop JARs against an official release; a corrupt jar is the usual cause.
2. If you deliberately repackage, ensure the default log4j properties resource stays on the classpath.
3. As a workaround, place a valid httpfs-log4j.properties in the HttpFS config dir so the classpath fallback is never used.

# pre-start: bundled default log4j resource must load
JAR=$(ls /opt/hadoop/share/hadoop/hdfs/httpfs-*.jar | head -1)
unzip -p "$JAR" httpfs-log4j.properties > /dev/null || {
  echo 'FATAL: default log4j resource missing/unreadable in jar'; exit 1; }
java -cp "$JAR" -e 'System.out.println(ClassLoader.getSystemResource("httpfs-log4j.properties") != null);' 2>/dev/null || true

When it happens

Trigger: Corrupted or truncated hadoop JARs after a partial download/deploy; a repackaged distribution that dropped httpfs's default log4j resource; exotic classloaders (some app servers) that cannot open the resource stream; disk-level read errors.

Common situations: Custom 'thin' Docker images stripping 'unused' resources out of JARs; fat-jar/shade plugin relocations that miss resource files; deployment artifacts copied over an unstable network.

Related errors

• [{0}] must be an absolute path [{1}]
• S01
• S02
• S05
• S06

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