pve-compose down should shut down the LXC container

[PoBruno]

Right now pve-compose down just passes the command through to docker compose down inside the LXC. The compose stack stops, but the container itself keeps running. That makes no sense. If I am bringing down the whole stack, I want the LXC off too.

The expected behavior is simple. Run docker compose down inside the container, then stop the container with pct stop.

current:   pve-compose down  ->  docker compose down  ->  LXC still running
expected:  pve-compose down  ->  docker compose down  ->  pct stop  ->  LXC off

This is the whole point of pve-compose. One command to manage the full lifecycle. Leaving the LXC running after down is just wasting resources for an empty container doing nothing.

[PoBruno]

Looking at the code. commands/down.sh is a passthrough, same pattern as ps, logs, restart. It just calls compose_passthrough "down" "$@" and thats it.

The fix is to turn down from a passthrough into a custom command. After compose down finishes, call pct stop $CTID. Need to read the CTID from lxc.json first.

cmd_down() {
    . "$PVC_LIB/lib/config.sh"
    . "$PVC_LIB/lib/compose.sh"
    . "$PVC_LIB/lib/lxc.sh"

    compose_passthrough "down" "$@"

    _ctid=$(config_get_ctid)
    if [ -n "$_ctid" ] && lxc_is_running "$_ctid"; then
        step "Stopping container $_ctid..."
        pct stop "$_ctid"
        msg "Container $_ctid stopped"
    fi
}

Small change. The compose down runs first so Docker cleans up properly, then we shut the LXC off. Mirrors how up works in reverse: up starts the LXC then runs compose, down runs compose then stops the LXC.

[PoBruno]

Actually thought about this more. Not so sure anymore.

In docker compose world, down stops containers and removes networks. The host machine stays on. Nobody expects docker compose down to shut down the server. So if pve-compose down kills the LXC, that is a behavior change from what docker compose users expect.

But then again, pve-compose is not docker compose. The whole point is that one LXC equals one stack. If the stack is down, what is the LXC doing? Just sitting there eating RAM with an empty Debian. On a home server with 16 or 32 GB, that matters when you have 10 containers.

The other side: sometimes you bring down a stack to debug something. You want to get into the LXC, check logs, fix a config, bring it back up. If down killed the LXC, you would need to start it manually first. That is annoying.

The real question is what down means in the pve-compose context. We already have stop (passthrough to compose stop), and we have destroy (full wipe including LXC removal). So the lifecycle is:

stop     = stop compose services, LXC stays running, fast restart
down     = remove compose services/networks, LXC stays running? or stops?
destroy  = remove everything including the LXC itself

I think the answer is yes, down should stop the LXC. The reasoning: up already handles the reverse seamlessly. Fast path boots the LXC and runs compose in under 3 seconds. So the cost of stopping the LXC on down is just 3 seconds on the next up. The benefit is freeing memory and CPU when the stack is not needed. If you need to debug inside the LXC, use pve-compose shell which starts the container anyway, or just pct start manually.

One thing to consider: down accepts flags like -v (remove volumes) and --rmi (remove images). Those flags should still pass through to docker compose before stopping the LXC. The order matters. Compose cleanup first, then LXC shutdown.