apache/seatunnel · warning

resetting default realm failed, current default realm will…

Error message

resetting default realm failed, current default realm will still be used.

What it means

KuduUtil.reloadKrb5conf sets the krb5.conf system property and then refreshes the JAAS/kerberos Config and resets the Hadoop KerberosName default realm. If org.ietf.jgss.GSSException/KrbException is thrown during refresh, the code logs a warning and continues with the previously loaded default realm, which may not match the new krb5.conf. The connector still uses the stale realm for Kerberos authentication.

Solutions

  1. Verify the krb5.conf path passed in config exists and is readable by the SeaTunnel process
  2. Validate krb5.conf syntax (default_realm under [libdefaults]) with `kinit -k -t keytab principal` before running the job
  3. Restart the JVM/node so the new krb5.conf takes effect from scratch if the stale realm persists
  4. Ensure the principal's realm matches the default_realm in krb5.conf

Example fix

// before
String krb5conf = "/etc/krb5.conf.broken"; // malformed file
loginAndReturnUgi(principal, keytab, krb5conf);
// after
Path path = Paths.get("/etc/krb5.conf");
if (!Files.isReadable(path)) throw new IOException("krb5.conf missing: " + path);
loginAndReturnUgi(principal, keytab, path.toString());
Defensive patterns

Strategy: validation

Validate before calling

java.nio.file.Path p = java.nio.file.Paths.get(krb5conf);
if (!java.nio.file.Files.isReadable(p)) throw new IllegalStateException("krb5.conf not readable: " + p);
// pre-validate: kinit -k -t keytab principal must succeed outside the JVM

Try / catch

try { loginAndReturnUgi(principal, keytab, krb5conf); } catch (Exception e) { throw new RuntimeException("Kerberos login failed (check krb5.conf default_realm)", e); }

Prevention

When it happens

Trigger: Calling loginAndReturnUgi with a kerberos principal/keytab when the new krb5.conf file is malformed, unreadable, or contains an invalid [libdefaults] default_realm entry, causing Config.refresh() or KerberosName.resetDefaultRealm() to throw KrbException.

Common situations: Pointing hadoop.security.authentication krb5 conf at a non-existent path, a krb5.conf copied from another cluster with a wrong default_realm, or a KDC change where the old realm stays cached in the JVM.

Understand the failure class

Background: "Invalid value" and "allowed values are" config errors: what your library rejected and how to fix it — this error's family across 41 libraries.

Related errors


AI-assisted analysis of apache/seatunnel@cf67b549a7 (2026-09-10). Data as JSON: /api/errors/30f2c3c93a809981. Report an issue: GitHub.

Appendix: source

Thrown at seatunnel-connectors-v2/connector-kudu/src/main/java/org/apache/seatunnel/connectors/seatunnel/kudu/util/KuduUtil.java:148

        }
        Configuration conf = new Configuration();
        conf.set(HADOOP_AUTH_KEY, KRB);
        UserGroupInformation.setConfiguration(conf);
        log.info(
                "Start Kerberos authentication using principal {} and keytab {}",
                config.getPrincipal(),
                config.getKeytab());
        return UserGroupInformation.loginUserFromKeytabAndReturnUGI(
                config.getPrincipal(), config.getKeytab());
    }

    private static void reloadKrb5conf(String krb5conf) {
        System.setProperty(KRB5_CONF_KEY, krb5conf);
        try {
            Config.refresh();
            KerberosName.resetDefaultRealm();
        } catch (KrbException e) {
            log.warn(
                    "resetting default realm failed, current default realm will still be used.", e);
        }
    }

    private static KuduClient getKuduClientInternal(
            CommonConfig config, ExecutorService executorService) {
        AsyncKuduClient.AsyncKuduClientBuilder builder =
                new AsyncKuduClient.AsyncKuduClientBuilder(
                                Arrays.asList(config.getMasters().split(",")))
                        .workerCount(config.getWorkerCount())
                        .defaultAdminOperationTimeoutMs(config.getAdminOperationTimeout())
                        .defaultOperationTimeoutMs(config.getOperationTimeout());
        if (executorService != null) {
            builder.nioExecutor(executorService);
        }
        return builder.build().syncClient();
    }

View on GitHub (pinned to cf67b549a7)