`mxcli run --ensure-db` can't start PostgreSQL on Arch Linux

[GG-O-BP]

Hi! I hit this while trying to bootstrap a fresh local session on Arch Linux.

When PostgreSQL is not already running,
mxcli run --local --setup --ensure-db only tries the service-manager helpers
service and Debian's pg_ctlcluster. Neither exists on Arch, so the command
exits even though the portable initdb, pg_ctl, postgres, and psql
commands are all available in PATH.

Environment

• OS: Arch Linux
• mxcli: nightly-20260730-d86fb696 (2026-07-30)
• Mendix project: 11.12.0
• PostgreSQL: 18.4
• Available: initdb, pg_ctl, postgres, psql
• Missing: service, pg_ctlcluster, pg_lsclusters

Steps to reproduce

Start with PostgreSQL installed but no server listening on port 5432:

$ pg_isready -h 127.0.0.1 -p 5432
127.0.0.1:5432 - no response

$ mxcli run --local --setup --ensure-db -p /path/to/App.mpr

Expected behavior

--ensure-db should initialize or start a usable local PostgreSQL server and
then ensure that the configured application role and database exist.

Actual behavior

Ensuring database...
  Starting local PostgreSQL...
Error: ensuring database: starting local PostgreSQL:
exec: "pg_ctlcluster": executable file not found in $PATH

The command exits with status 1 without trying the portable PostgreSQL tools.

What seems to be happening

cmd/mxcli/docker/ensuredb.go currently has these startup attempts in
startLocalPostgres():

attempts := [][]string{
    {"service", "postgresql", "start"},
    {"pg_ctlcluster", "--", "start"},
}

Neither command exists on Arch, and there is no fallback using initdb and
pg_ctl.

When I start a compatible PostgreSQL instance separately and the configured
application role/database already exist, the same mxcli command completes.
That confirms the immediate failure is in the local server bootstrap path.

Workaround

Initialize and start a user-owned PostgreSQL cluster manually, create the
application role/database, and then run mxcli without relying on its database
bootstrap:

$ initdb -D <data-directory>
$ pg_ctl -D <data-directory> \
    -o "-h 127.0.0.1 -p 5432 -k <socket-directory>" start
$ mxcli run --local -p /path/to/App.mpr

[GG-O-BP]

I'm going to take this one and send a fix.

I reproduced it locally and traced the first failure to
startLocalPostgres(). I'll keep the existing service-manager paths, then add
an initdb/pg_ctl fallback for systems like Arch where those helpers aren't
available or don't produce a ready server. The fallback should use
user-writable mxcli state, be safe to run repeatedly, and avoid depending on a
postgres OS account or passwordless sudo.

I'll add coverage for an already-running server, first-time initialization,
repeated --ensure-db runs, missing tools, and startup failures. I'll link the
PR here when it's ready.

[GG-O-BP]

Opened #824 with the minimal fix.

It keeps the existing service / pg_ctlcluster attempts, verifies that a service actually becomes ready, and falls back to a user-owned initdb / pg_ctl cluster under ~/.mxcli/postgres when no service does. Successful initialization is reused, an already-running cluster is left alone, and role/database provisioning connects directly as the clusters postgressuperuser without requiring apostgresOS account or passwordlesssudo`; the existing sudo path remains for system clusters.

Focused tests cover ready and ineffective services, missing tools, first initialization, repeated and already-running invocations, startup failure, and direct/sudo superuser selection. The flow was also verified against PostgreSQL 18.4 in the reported Arch-shaped environment.