@kapa.ai, if I stop an EC2 on which I have airbyte installed with abctl, then start the instance again will it start automatically or I should do some config for this ?

Thinking completed The provided knowledge sources do not explicitly state whether

abctl

automatically resumes your Airbyte cluster upon an EC2 reboot without manual intervention or configuration. However, based on the documentation for setting up an EC2 instance with `abctl`: 1. Docker Engine Boot Configuration: At the operating system level, you must configure the Docker service to start on system boot. During setup, you should enable Docker via systemd [EC2 with abctl]:sudo systemctl enable dockerIf Docker is not enabled on boot, containers cannot start automatically when the EC2 instance restarts. 2. Starting or Checking Airbyte: Under the hood,

abctl

uses Docker to run a local

kind

Kubernetes cluster [abctl overview]. Once your EC2 instance restarts:abctl local statusabctl local install --host [HOSTNAME]_(Note: Do not run

abctl local uninstall

, as that can remove existing configurations [Issue 64508])._ ◦ Check if the cluster and services are running using: ◦ If the cluster or deployments do not resume on their own, re-run the install command (with your original flags) to detect the existing cluster and bring the services back up [Install and manage local Airbyte]: 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, I see taht I can use

abctl local deployments --restart airbyte-abctl-connector-builder-server

to restart a particular deployment, does it matter in whihc order I restart the deployments?

Thinking completed The knowledge sources do not explicitly state whether the order matters when restarting individual Airbyte deployments using

abctl local deployments --restart

. The documentation notes that

abctl local deployments

can be used to display Kubernetes deployment information or restart an entire deployment using the

--restart

flag (for example,

abctl local deployments --restart webapp

or without arguments to restart deployments) [abctl reference; Install and manage local Airbyte]. However, there are no specific instructions or documented constraints regarding a required restart sequence for individual pods or services like

airbyte-abctl-connector-builder-server

. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, after restart of the deply airbyte-abctl-temporal I get

{
  "level": "info",
  "ts": "2026-09-18T11:45:40.070Z",
  "msg": "invalid tq name",
  "service": "frontend",
  "error": "task queue family name cannot have prefix /_sys/ /_sys/CONNECTION_UPDATER/3",
  "proto": [
    "/_sys/CONNECTION_UPDATER/3"
  ],
  "logging-call-at": "/home/runner/work/docker-builds/docker-builds/temporal/client/matching/metric_client.go:188"
}

Thinking completed I'm sorry, but the provided knowledge sources do not contain information explaining this specific error message (

"invalid tq name"

,

"task queue family name cannot have prefix /_sys/"

) or how to resolve it after restarting the Temporal deployment. While the knowledge sources show that Temporal internal queues use names with the

/_sys/

prefix (such as

/_sys/CONNECTION_UPDATER/1

or

/_sys/CHECK_CONNECTION/1

) [Github Issue 59730], there are no details explaining why Temporal rejects

/_sys/CONNECTION_UPDATER/3

as an invalid task queue family name or what configuration steps are needed to fix it. 👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.

@kapa.ai, how to check what DB endpoint currently is configured in airbyte ?

Thinking completed The knowledge sources do not explicitly describe a single, dedicated command for inspecting the currently configured database endpoint. However, based on the provided logs and configuration files, you can determine or check the configured database endpoint using the following methods depending on your setup: 1. Check the Pod or Container Startup Logs During initialization, services like

airbyte-server

,

airbyte-worker

, and

bootloader

log the database connection string and host they are connecting to. You can inspect the logs of your server or worker pod/container [External Postgres Forum Post; Github Issue 75614]: • For Kubernetes /

abctl

deployments:kubectl logs -l app.kubernetes.io/name=server -n namespace_(Or check the pod directly, e.g.,

kubectl logs airbyte-server-...

)_ Look for lines that display the JDBC database connection URL, such as:

INFO i.a.c.EnvConfigs(getEnvOrDefault) - Using default value for environment variable CONFIG_DATABASE_URL: 'jdbc:postgresql://<hostname>:5432/<dbname>'

or Flyway database connection messages:

INFO o.f.c.i.l.s.Slf4jLog(info) - Database: jdbc:postgresql://<hostname>:5432/<dbname> (PostgreSQL ...)

2. Check the Environment Variables or ConfigMaps In containerized and Kubernetes environments, the database connection parameters are passed via environment variables (such as

DATABASE_HOST

,

DATABASE_PORT

,

DATABASE_DB

, or

DATABASE_URL

/

CONFIG_DATABASE_URL

) [Github Issue 65129; Forum Post 729]. • Kubernetes / `abctl`: Check the Airbyte environment ConfigMap (typically named

airbyte-abctl-airbyte-env

or similar) [Github Issue 65129]:kubectl get configmap airbyte-abctl-airbyte-env -o yamlLook for

DATABASE_HOST

,

DATABASE_PORT

,

DATABASE_DB

, or

DATABASE_URL

. • Docker Compose: Check your

.env

file for

DATABASE_HOST

or

DATABASE_URL

[Forum Post 729; Forum Post 5256]. 3. Check your values.yaml File (Helm / abctl) If you deployed Airbyte using Helm or

abctl

with a custom

values.yaml

file, the configured external host and port are defined under the

global.database

section [External DB Docs]:

global:
  database:
    type: external
    host: "your-db-hostname"
    port: "5432"
    name: "your_db_name"

👍 0 button 👎 0 button ℹ️ Tip: Mention @kapa.ai in the thread for follow-ups or DM the app for 1-to-1 help.