-
Notifications
You must be signed in to change notification settings - Fork 1
Troubleshooting
First move, always. Re-run with -o json. Failure envelopes carry the remote command BaryoVM
generated, and reading that command is usually the whole diagnosis.
baryovm stack release app -o jsonThe compose directory or .env is root-owned, which is a fine posture for a file holding a database
password. Register the stack with --sudo:
baryovm stack add app --vm oracle --path /opt/app --sudoRead the --sudo section of Concepts first: three things change with it, including file
ownership after a sync.
Two different causes, and the message does not distinguish them.
Either the SSH user has no passwordless sudo at all, or it has passwordless sudo for specific
commands only. BaryoVM elevates a hook by running a whole shell as root, so a sudoers line granting
one program is refused. Grant the shell, or drop --sudo and put the elevation inside each command.
All sudo here is sudo -n, deliberately: without it, a host that wants a password hangs the session
until it times out instead of failing.
The VM offered a different SSH host key from the one recorded on the first connection. The error prints both fingerprints. A rebuilt VM is the usual reason, and so is someone else answering on that address, and BaryoVM cannot tell them apart. If you rebuilt it, check the new fingerprint on the machine, then:
baryovm vm forget-key demoThe next connection learns the new key. There is no flag that turns the check off.
Strict mode (BARYOVM_STRICT_HOST_KEYS=1 or --strict-host-keys) refuses a host it has no key
for, which is what a CI job wants. The error prints the offered fingerprint and the ssh-keyscan
line that records it in ~/.baryovm/known_hosts. Check the fingerprint against the machine, record
it, and run again. Better, commit the expected known_hosts or keep it in a secret, so the pin is
reviewed rather than fetched on every run.
Check baryovm doctor. rsync and ssh must be on your local PATH; the built-in Go SSH client
does not cover that transfer. On Windows, run under WSL.
If the VM is on a non-standard SSH port, that was a real bug fixed in 0.3.0. Upgrade.
Read state in the JSON, which exists precisely because empty and broken used to look identical:
-
read, there are logs, here they are -
silent, containers are running and wrote nothing to stdout, typical of an app logging to a file -
not-running, nothing is up so there is nothing to log; trystack deploy -
unknown, the container check did not answer either; trystack ps
By design, and the error says which of four rules it hit: no autoUpdate, no healthUrl,
--no-backup combined with --auto, or no database backup configured at all. Each exists so an
unattended update can tell a healthy start from a crash loop and go back when it cannot.
If the stack genuinely has no database, record that once rather than working around it:
baryovm stack set-update app --no-databaseTwo causes, both handled since 0.4.0. A container an earlier recreate left renamed (<id>_<name>)
is removed and the up is tried once more (#57). A
name held by a container started by hand with docker run is caught before any work, and the error
names the container and the docker rm -f that frees it; nothing is removed for you
(#1). On 0.3.0 or older, upgrade, or remove the
container on the VM and release again.
Before 0.4.0, re-adding a stack replaced the whole record, so any flag not passed again was cleared,
including the update policy. Since 0.4.0 re-adding changes only the fields its flags name
(#63). Upgrade, then set the policy again with
stack set-update.
A failing command prints two envelopes today. Read the first, or split on the top-level object boundary. Tracked as #10, and described in The JSON contract.
Open an issue. Include the command, the
-o json envelope, and baryovm version. The envelope's remote command is the part that usually
answers it.