apache/seatunnel · error · SeaTunnelException

check connectivity failed,

Error message

check connectivity failed, 

What it means

doKerberosAuthentication calls UserGroupInformation.loginUserFromKeytab; any IOException from that low-level login (file IO, Kerberos protocol failures) is rethrown as a plain SeaTunnelException with the message prefix 'check connectivity failed, '. It is the raw底层 failure that error 1623 usually wraps.

Source

Thrown at seatunnel-connectors-v2/connector-iceberg/src/main/java/org/apache/seatunnel/connectors/seatunnel/iceberg/IcebergCatalogLoader.java:176

            Configuration configuration, String principal, String keytabPath) {
        if (StringUtils.isBlank(principal) || StringUtils.isBlank(keytabPath)) {
            log.warn(
                    "Principal [{}] or keytabPath [{}] is empty, it will skip kerberos authentication",
                    principal,
                    keytabPath);
        } else {
            configuration.set("hadoop.security.authentication", "kerberos");
            UserGroupInformation.setConfiguration(configuration);
            try {
                log.info(
                        "Start Kerberos authentication using principal {} and keytab {}",
                        principal,
                        keytabPath);
                UserGroupInformation.loginUserFromKeytab(principal, keytabPath);
                UserGroupInformation loginUser = UserGroupInformation.getLoginUser();
                log.info("Kerberos authentication successful,UGI {}", loginUser);
            } catch (IOException e) {
                throw new SeaTunnelException("check connectivity failed, " + e.getMessage(), e);
            }
        }
    }
}

View on GitHub (pinned to cf67b549a7)

Solutions

1. Read the suffix after 'check connectivity failed, ' for the real IOException cause and fix it (file path, KDC reachability, realm)
2. Confirm the keytab file exists and is readable by the SeaTunnel worker process user on each node
3. Verify KDC connectivity from workers: kinit -kt <keytab> <principal> or nc/ telnet to the KDC port from the same host
4. Set java.security.krb5.conf correctly and ensure the principal exactly matches an entry in the keytab

Example fix

// fix usually on the environment, not code:
// before: keytab only on driver node
// after: scp /etc/security/keytabs/user.keytab to all worker nodes and chmod 400 + chown seauser

File keytab = new File(keytabPath);
if (!keytab.canRead()) throw new IllegalStateException("Keytab unreadable: " + keytabPath);
UserGroupInformation.setConfiguration(conf);
// Optionally dry-run: UserGroupInformation.loginUserFromKeytabAndReturnUGI(principal, keytabPath);

try {
  doKerberosAuthentication(conf, principal, keytabPath);
} catch (SeaTunnelException e) {
  // e.getCause() is the original IOException — inspect it for file/KDC issues
  log.error("Kerberos login failed: {}", e.getCause(), e);
}

When it happens

Trigger: doKerberosLogin (with kerberos principal+keytab configured) invokes this public method and UserGroupInformation.loginUserFromKeytab throws IOException — e.g. keytab file missing/unreadable, KDC unreachable, principal not in keytab.

Common situations: Keytab not distributed to worker nodes; KDC hostname wrong or firewalled (connection timeouts); krb5.conf absent so default realm cannot be resolved; expired or corrupted keytab.

Related errors

• CommonErrorCode.KERBEROS_AUTHORIZED_FAILED
• KERBEROS_AUTHORIZED_FAILED
• Failed to login user from keytab : ${keytabPath} and kerbero
• Kerberos re-login from keytab failed: {}
• Kerberos authentication is not configured, it will skip kerb

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