Container is Ephemeral, yet Stopped?

sklarsa · June 19, 2026, 2:27am

I have a container in a weird state, and it’s been stuck there for a while.

How can a container be ephemeral and stopped?

incus --version 6.21

root@cloud-arm-7:~# incus info hetzner-incus-arm-1
Name: hetzner-incus-arm-1
Description:
Status: STOPPED
Type: container (ephemeral)
Architecture: aarch64
Created: 2026/06/18 13:27 UTC
Last Used: 1970/01/01 00:00 UTC

Most of the daemon logs are dnsmasq-related, but these ones stand out:
Jun 18 13:27:42 cloud-arm-7 incusd[8263]: time=“2026-06-18T13:27:42Z” level=error msg=“SFTP server stopped with error” err=“signal: terminated” instance=hetzner-incus-arm-0 instanceType=container project=default stderr=

Jun 18 20:25:42 cloud-arm-7 incusd[8263]: time=“2026-06-18T20:25:42Z” level=warning msg=“Failed to retrieve network information via netlink” instance=hetzner-incus-arm-0 instanceType=container pid=521820 project=default
Jun 18 20:25:42 cloud-arm-7 incusd[8263]: time=“2026-06-18T20:25:42Z” level=error msg=“Error calling 'forknet” err=“Failed to run: /opt/incus/bin/incusd forknet info – 521820 3: exit status 1 (Failed setns to container network namespace: No such file or directory)” instance=hetzner-incus-arm-0 instanceType=container pid=521820 project=default
Jun 18 20:25:42 cloud-arm-7 incusd[8263]: time=“2026-06-18T20:25:42Z” level=error msg=“Failed to retrieve PID of executing child process” instance=hetzner-incus-arm-0 instanceType=container project=default

For context, I’m running a single CI job and then issuing shutdown so the container gets reaped by the incus daemon. Then I’m running a separate host process to create a new container.

github.com/sklarsa/incus-azure-pipelines

provision/run_agent.sh

main

#!/bin/bash
set -uo pipefail

if [ "$(id -u)" == "0" ]; then
    exec sudo -H -u agent "$0" "$@"
fi

LOG_FILE="${LOG_FILE:-/home/agent/azp-agent.log}"
exec >> "$LOG_FILE" 2>&1

echo "uid=$(id -u)"
echo "gid=$(id -g)"
echo "groups=$(id -Gn)"

export HOME=/home/agent
cd "${HOME}"

TOKEN_FILE="/home/agent/.token"
if [[ ! -f "$TOKEN_FILE" ]]; then
    echo "Token file not found"

This file has been truncated. show original

enriched · June 19, 2026, 10:42am

It looks like the container has never been started, so I assume the separate host process is working properly to create the new container.

It’s possible your ci job and the separate host process are not synced, the separate host process is running properly, but the ci job is not finishing or something before the separate host process runs, kills the container and recreates it.

(You may know some or all of this:)
When you create a container, incus sets some defaults that appear in your output. (Stopped, last used timestamp == 0) For instance, when you use OCI to pull a container image in from Docker Hub or ghcr, incus uses skopeo to pull the image and create an incus container image and create that instance. Future instance creation just uses the cached incus container image to create the instance. (If the cached container image needs to be updated, I’ve found just deleting the image, then creating a temporary instance that pulls the new OCI image and builds the rootfs, etc. then deleting the temporary instance is the most efficient.)

You might also look into using the incus rebuild <image name or fingerprint (unique partials ok)> <instance name> command. The incus rebuild command wipes the instance root disk and re-initializes it with a new image (or empty volume). (NOTE: incus assumes that the first : in the image or instance is a separator between remote:image or remote:instance, so especially in a script, I would recommend using the fingerprint or alias instead of the name.)

You can get the fingerprint from the incus image list command, and especially since you are using a pre-built base image, using the fingerprint may provide some error checking that the base image has not changed. Or you can also look into incus image alias to create an alias for your base image.