Skip to main content
Version: Next

Application command line

bin/seatunnel-application.sh is the only entry point of Application Mode. It exposes three operations, all of which target one external resource platform using matching deployment options, so status and cancel see exactly the application submit created.

Synopsis​

bin/seatunnel-application.sh submit -t <target> [-a application.config] [-Dkey=value ...] [-c job.conf]
bin/seatunnel-application.sh status -t <target> --id APPLICATION_ID -a application.config [--wait] \
[--wait-timeout <ms>] [--wait-interval <ms>]
bin/seatunnel-application.sh cancel -t <target> --id APPLICATION_ID -a application.config

The built-in help lists every option:

bin/seatunnel-application.sh -h
Usage: seatunnel-application.sh [options] submit | status | cancel
Options:
-a, --application-config Optional HOCON deployment file, e.g.
application.config (not the job file)
-c, --config SeaTunnel job configuration file (required for
submit unless the provider supplies it, for
example kubernetes.job-config-file)
-h, --help Show the usage message
--id Platform application ID (required for
status/cancel)
--job-id Optional native Zeta job ID for submit
--restore-job-id Historical Zeta job ID whose latest checkpoint
restores this new application
* -t, --target External resource platform: kubernetes
--wait Wait for completion (submit/status only; default:
return immediately) (default: false)
--wait-timeout Maximum time in milliseconds that --wait polls for
a terminal status before failing with the last
observed status; 0 waits indefinitely (default: 0)
--wait-interval Status poll interval in milliseconds while --wait
blocks (default: 500)
-D Override a non-sensitive deployment option:
-Dkey=value (syntax: -Dkey=value) (default: {})

Arguments​

ArgumentOperationsMeaning
submit / status / cancelallOperation, the first positional argument
-t, --targetallResource platform that runs the application
-c, --configsubmitSeaTunnel job configuration file; optional when the platform carries the job, such as a mounted job.conf
-a, --application-configallOptional deployment file with common and platform options; options can also be supplied through -D
-Dkey=valueallOverride one non-sensitive application.* or kubernetes.* deployment option, for example -Dapplication.worker-count=4; repeatable. Job ${...} variables are resolved inside the Pod, not on the submitting host
--idstatus, cancelPlatform application ID printed by submit
--waitsubmit, statusPoll until a terminal status
--wait-timeout <ms>submit, statusMaximum time in milliseconds that --wait polls before failing with the last observed status; 0 (the default) waits indefinitely. Requires --wait
--wait-interval <ms>submit, statusStatus poll interval in milliseconds while --wait blocks; default 500. Requires --wait
--job-idsubmitNative Zeta job ID to use for this application instead of a generated one
--restore-job-idsubmitJob ID whose latest durable checkpoint restores the new application

Operations​

OperationWhat it doesResult
submitLocalizes the job, creates the application on the platform and starts itPrints the application ID and the native job ID
statusReads the platform state and maps it to an ApplicationStatusPrints the application ID and status; a successful plain query exits 0; with --wait, follows the waiting exit codes
cancelRemoves the application and the resources it ownsPrints the application ID and the cancellation result

Submit returns immediately​

submit returns as soon as the platform accepted the started application. Image pulls, admission and scheduling therefore never fail the command; add --wait to wait for the terminal status inside the same command:

bin/seatunnel-application.sh submit -t <target> -a application.config --wait

The job comes from -c or from a file the platform mounts inside the application, for example kubernetes.job-config-file. A submission that provides neither is rejected before the first resource is created. Values written as ${VAR} are resolved inside the running application, never on the submitting host, so platform-managed credentials can be injected through the environment.

The deployment file (-a) is optional when -D supplies the required deployment options. When both are given, -D overrides file values. Platform validation still applies: omitting -a does not make incomplete deployment settings valid.

Status and waiting​

status reports one snapshot by default and polls that snapshot until it becomes terminal when --wait is given. --wait-timeout fails the wait with the last observed status when the limit is reached; the default 0 waits indefinitely, like an attached client. --wait-interval sets how often the status is polled. The platform-independent states are:

StatusMeaning
CREATEDThe platform accepted the submission but has not started the control plane
DEPLOYINGThe platform is provisioning the control plane
RUNNINGThe application is running; workers or the job may still be starting
SUCCEEDEDThe job completed successfully
FAILEDStartup, execution or reportable cleanup failed
CANCELEDThe platform reported a cancellation
UNKNOWNA known application has a platform state that cannot yet be mapped

SUCCEEDED, FAILED and CANCELED are terminal; --wait stops there. It also stops at UNKNOWN when the platform cannot determine the application outcome. For both status --wait and submit --wait, FAILED exits with code 1, while UNKNOWN exits with code 2: the result is indeterminate, not a confirmed failure or success. SUCCEEDED and CANCELED still exit 0. A plain status prints the snapshot and exits 0, including for FAILED and UNKNOWN; query errors still exit non-zero. Do not interpret every non-zero exit as a failed application:

if bin/seatunnel-application.sh status -t <target> --id "$APP_ID" -a application.config --wait; then
result=0
else
result=$?
fi
case "$result" in
0) echo "application status reported; inspect the printed status" ;;
2) echo "application $APP_ID outcome is unknown" ;;
*) echo "application failed or the command could not complete (exit $result)" ;;
esac

Cancel​

cancel asks the platform to remove the application. Every resource the application owns is deleted with it, while objects managed outside SeaTunnel are left untouched. How long a canceled or finished application stays queryable depends on the platform retention policy.

Each platform guide documents the platform-specific behavior behind these operations.