[envestcc]

Problem

checkDockerCompose() requires the standalone docker-compose v1 binary:

docker-compose --version > /dev/null 2>&1
if [ $? -eq 127 ];then
    echo -e "$RED docker-compose command not found $NC"
    exit 1
fi

That binary is end-of-life. Current Docker packages ship Compose as a CLI plugin invoked as docker compose and do not install docker-compose at all. On any such host these scripts exit 1 before doing any work.

For setup_fullnode.sh this is the first thing main() does after the docker permission check, so it never reaches config download, image pull, or the snapshot code. A fresh gateway or delegate install is impossible without hand-installing a deprecated binary or dropping in a shim.

Verified on a host running Docker 29.5.3 with Compose v5.1.4 as a plugin and no docker-compose binary:

$ bash setup_fullnode.sh testnet --auto --home=/…
 docker-compose command not found
Please install it first
exit=1

Three of our own internal hosts are in this state.

Changes

Each script now detects what is available, preferring the plugin and falling back to the legacy binary:

if docker compose version > /dev/null 2>&1;then
    COMPOSE_CMD="docker compose"
elif docker-compose --version > /dev/null 2>&1;then
    COMPOSE_CMD="docker-compose"
else
    …exit 1 with an actionable message…
fi

Call sites invoke $COMPOSE_CMD, intentionally unquoted so docker compose splits into command plus subcommand.

All five scripts carried the same copied check:

Script	Invocations rewritten
setup_fullnode.sh	5 (up -d --no-deps monitor, up -d --no-recreate, up -d iotex, ps, ps iotex)
update_silence.sh	3
setup_fullnode_marketplace.sh	2
stop_fullnode.sh	1 (stop)
setup_monitor_alert.sh	0 — see below

In setup_monitor_alert.sh the check is vestigial: that script never invokes Compose, so the gate could only ever produce a false failure. It is fixed rather than removed to keep the five scripts consistent, but removing it outright would also be reasonable.

Verification

On the same host, with the fixed scripts:

• checkDockerCompose() passes and the script proceeds through config download and image pull.
• $COMPOSE_CMD up -d iotex — Network monitor_default Created, Container iotex Created, Container iotex Started.
• $COMPOSE_CMD ps iotex — reports the container.
• stop_fullnode.sh's $COMPOSE_CMD stop — Container iotex Stopping / Stopped, container reaches Exited.
• bash -n clean on all five.

The test node was started without --snapshot, so it then crash-looped syncing from genesis on an unrelated pre-existing problem — see below. That happens well after Compose has done its job; the container was created, started, queried and stopped through the plugin.

Unrelated issue found while testing (not fixed here)

A fresh install that syncs from genesis dies with:

fatal  Failed to start server.
error: failed to get tip height: 401 Unauthorized: account disabled

The Infura key baked into the shipped config_testnet.yaml (gravityChainAPIs) is disabled, and the committee needs the gravity chain to fetch legacy delegate election data. README "Optional 3" already tells operators to substitute their own key when syncing from height 0, so this is documented rather than new — but the dead default produces a restart loop with a stack trace instead of a clear message. Snapshot-based installs are unaffected: poll.db ships in the snapshot and the committee logs stop syncing without ever calling out to Ethereum.

Worth its own issue.

Relation to #337

Independent, no overlap in the touched hunks. They are complementary for the case that prompted #337 — an operator building a gateway node from a snapshot:

• Following the README commands by hand: fix: extract snapshot tarballs into $IOTEX_HOME/data #337 alone is sufficient.
• Running setup_fullnode.sh --auto --snapshot plugin=gateway on a host with a current Docker: both are needed, since without this PR the script exits before reaching the code fix: extract snapshot tarballs into $IOTEX_HOME/data #337 fixes.

🤖 Generated with Claude Code