apache/hadoop · error · ExitUtil.ExitException

EXIT_SERVICE_CREATION_FAILURE(56)

EXIT_SERVICE_CREATION_FAILURE(56)

Error message

Could not create ${classname} because it is not a Configuration class/subclass

What it means

ServiceLauncher.loadConfigurationClasses() instantiates every configuration class named in the launcher's configuration-class list (confClassnames, e.g. the --confclass launch argument) so their static resources load. ClassNotFound is skipped at DEBUG (not on classpath is fine), any other instantiation error is logged and skipped - but a class that loads and constructs yet is not an instanceof org.apache.hadoop.conf.Configuration triggers ExitUtil.ExitException EXIT_SERVICE_CREATION_FAILURE (56): "Could not create <classname> because it is not a Configuration class/subclass", and the launcher exits with code 56.

Source

Thrown at hadoop-common-project/hadoop-common/src/main/java/org/apache/hadoop/service/launcher/ServiceLauncher.java:431

  /**
   * @return This creates all the configurations defined by
   * {@link #getConfigurationsToCreate()} , ensuring that
   * the resources have been pushed in.
   * If one cannot be loaded it is logged and the operation continues
   * except in the case that the class does load but it isn't actually
   * a subclass of {@link Configuration}.
   * @throws ExitUtil.ExitException if a loaded class is of the wrong type
   */
  @VisibleForTesting
  public int loadConfigurationClasses() {
    List<String> toCreate = getConfigurationsToCreate();
    int loaded = 0;
    for (String classname : toCreate) {
      try {
        Class<?> loadClass = getClassLoader().loadClass(classname);
        Object instance = loadClass.getConstructor().newInstance();
        if (!(instance instanceof Configuration)) {
          throw new ExitUtil.ExitException(EXIT_SERVICE_CREATION_FAILURE,
              "Could not create " + classname
              + " because it is not a Configuration class/subclass");
        }
        loaded++;
      } catch (ClassNotFoundException e) {
        // class could not be found -implies it is not on the current classpath
        LOG.debug("Failed to load {} because it is not on the classpath",
            classname);
      } catch (ExitUtil.ExitException e) {
        // rethrow
        throw e;
      } catch (Exception e) {
        // any other exception
        LOG.info("Failed to create {}", classname, e);
      }
    }
    return loaded;
  }

View on GitHub (pinned to 2add963021)

Solutions

1. Remove the offending entry or replace it with a class that actually extends org.apache.hadoop.conf.Configuration (e.g. org.apache.hadoop.yarn.conf.YarnConfiguration).
2. Check for shadowing: run the class with -verbose:class or inspect the fat jar for duplicate class names.
3. Confirm the class has a public no-arg constructor; classes failing instantiation are merely logged, so the 56 exit specifically means wrong type.

Example fix

# before
hadoop ... --confclass org.example.AppConstants   # loads, but not a Configuration
# exit code 56: "Could not create org.example.AppConstants because it is not a Configuration class/subclass"
# after
hadoop ... --confclass org.apache.hadoop.yarn.conf.YarnConfiguration

for (String name : confClassnames) {
  Class<?> c = Class.forName(name, false, getClass().getClassLoader());
  if (!Configuration.class.isAssignableFrom(c)) {
    LOG.warn("Skipping non-Configuration class {}", name);
  }
}

static Optional<Class<? extends Configuration>> asConfigurationClass(
    String name, ClassLoader cl) {
  try {
    Class<?> c = cl.loadClass(name);
    return Configuration.class.isAssignableFrom(c)
        ? Optional.of(c.asSubclass(Configuration.class))
        : Optional.empty();
  } catch (ClassNotFoundException e) {
    return Optional.empty();
  }
}

When it happens

Trigger: Passing a class to the launcher's configuration-class list that is on the classpath and has a public no-arg constructor but does not extend Configuration - e.g. a settings/constants class, a YarnConfiguration lookalike from the wrong package, or a class whose simple name collides with the intended Configuration subclass.

Common situations: Hand-built launch commands with --confclass entries; fat jars where a different same-named class shadows the intended Configuration subclass; copy-paste from docs pointing at non-Configuration classes.

Related errors

• No KeyProviderFactory for ${uri} in ${KEY_PROVIDER_PATH}
• Could not find configured fencing method {}
• Class {} does not implement FenceMethod
• Error creating plugin: {}
• Socket Factory class not found: ${cnfe}

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