1
0
Fork 0
mirror of https://github.com/louislam/dockge.git synced 2026-03-03 02:06:55 -05:00

Docker Stack Shows "Exited" Status Due to One-Time Execution Container #211

Open
opened 2026-02-20 13:12:14 -05:00 by deekerman · 2 comments
Owner

Originally created by @Tealk on GitHub (May 24, 2025).

⚠️ Please verify that this bug has NOT been reported before.

  • I checked and didn't find similar issue

🛡️ Security Policy

Description

There was a similar issue before.

When deploying the Docker stack, the status is displayed as "Exited" because one of the containers, which is designed to run only once during startup (e.g., a migration job), is not running.

In this case, the affine_migration_job container completes its task and exits as expected, but this causes the entire stack to appear as if it is in an "Exited" state, which can be misleading.
Image

👟 Reproduction steps

  1. Deploy the Docker stack with a container that runs a one-time job (e.g., a migration task).
  2. Observe the stack status after the one-time execution container finishes its task and exits.

👀 Expected behavior

The stack should show a "Healthy" or "Running" status if all other containers are running as expected, even if a one-time execution container has exited.

😓 Actual Behavior

The stack shows an "Exited" status, which might suggest an issue with the deployment, even though the behavior of the one-time execution container is correct.

Dockge Version

1.5.0

💻 Operating System and Arch

Debian GNU/Linux 12 (bookworm)

🌐 Browser

LibreWolf 138.0.4-1

🐋 Docker Version

Docker version 24.0.2

🟩 NodeJS Version

No response

📝 Relevant log output


Originally created by @Tealk on GitHub (May 24, 2025). ### ⚠️ Please verify that this bug has NOT been reported before. - [x] I checked and didn't find similar issue ### 🛡️ Security Policy - [x] I agree to have read this project [Security Policy](https://github.com/louislam/dockge/security/policy) ### Description There was a similar [issue](https://github.com/louislam/dockge/issues/11#issue-1989498337) before. When deploying the Docker stack, the status is displayed as "Exited" because one of the containers, which is designed to run only once during startup (e.g., a migration job), is not running. In this case, the affine_migration_job container completes its task and exits as expected, but this causes the entire stack to appear as if it is in an "Exited" state, which can be misleading. ![Image](https://github.com/user-attachments/assets/57d0206d-7bba-4a76-be79-8be535057db9) ### 👟 Reproduction steps 1. Deploy the Docker stack with a container that runs a one-time job (e.g., a migration task). 2. Observe the stack status after the one-time execution container finishes its task and exits. ### 👀 Expected behavior The stack should show a "Healthy" or "Running" status if all other containers are running as expected, even if a one-time execution container has exited. ### 😓 Actual Behavior The stack shows an "Exited" status, which might suggest an issue with the deployment, even though the behavior of the one-time execution container is correct. ### Dockge Version 1.5.0 ### 💻 Operating System and Arch Debian GNU/Linux 12 (bookworm) ### 🌐 Browser LibreWolf 138.0.4-1 ### 🐋 Docker Version Docker version 24.0.2 ### 🟩 NodeJS Version _No response_ ### 📝 Relevant log output ```shell ```
Author
Owner

@tclayson commented on GitHub (Jun 6, 2025):

I'm also having this issue. I have a container that waits for my network drive to become available and then exits to allow other containers to boot up (that rely on the network drives).

Very confusing to see in the interface that this stack has exited when it's working perfectly.

I think the challenge exists in this commit: github.com/louislam/dockge@c8770a9605

When there are multiple statuses for a stack (e.g. exited(1), running(1)) Dockge first checks if any one of the statuses are exited(1), which marks the stack as exited even if it's just an init script or something.

A way to fix this would be to say instead if any of the statuses are running(1) first, then mark it as active. This appears to be how docker compose ls works. If any of the statuses are running(1) then the stack status is running(1). Marking this stack as active would replicate the same output as docker compose ls.

Alternatively, perhaps there's an option to check the exit code of the containers and decide if exited(1) is relevant?

Running docker ps -a --filter "status=exited" --format json gives an output of exited containers:

{
  "Command": "\"sh -c '\\n  apk add -…\"",
  "CreatedAt": "2025-06-06 09:22:45 +0000 UTC",
  "ID": "2bae64ae4d92",
  "Image": "alpine",
  "Labels": "...",
  "LocalVolumes": "0",
  "Mounts": "",
  "Names": "wait_for_nfs_duplicati",
  "Networks": "duplicati-backups_default",
  "Ports": "",
  "RunningFor": "42 minutes ago",
  "Size": "0B",
  "State": "exited",
  "Status": "Exited (0) 40 minutes ago"
}

In here, we can see the exit code (0) indicates this container exited successfully (I think 😅 ). Could we use this as an indicator that the status should be active still and not exited maybe?

Another command you could use is docker inspect wait_for_nfs_duplicati --format='{{.State.ExitCode}}' which will output either 0 for successful exit or any other number for failed. But this would require iterating through all containers in a stack.

Thanks!

@tclayson commented on GitHub (Jun 6, 2025): I'm also having this issue. I have a container that waits for my network drive to become available and then exits to allow other containers to boot up (that rely on the network drives). Very confusing to see in the interface that this stack has exited when it's working perfectly. I think the challenge exists in this commit: https://github.com/louislam/dockge/commit/c8770a96055d5f37502248099bc4ea4aec94b2b4 When there are multiple statuses for a stack (e.g. `exited(1), running(1)`) Dockge first checks if any one of the statuses are `exited(1)`, which marks the stack as `exited` even if it's just an init script or something. A way to fix this would be to say instead if any of the statuses are `running(1)` first, then mark it as active. This appears to be how `docker compose ls` works. If any of the statuses are `running(1)` then the stack status is `running(1)`. Marking this stack as `active` would replicate the same output as `docker compose ls`. Alternatively, perhaps there's an option to check the exit code of the containers and decide if `exited(1)` is relevant? Running `docker ps -a --filter "status=exited" --format json` gives an output of exited containers: ``` { "Command": "\"sh -c '\\n apk add -…\"", "CreatedAt": "2025-06-06 09:22:45 +0000 UTC", "ID": "2bae64ae4d92", "Image": "alpine", "Labels": "...", "LocalVolumes": "0", "Mounts": "", "Names": "wait_for_nfs_duplicati", "Networks": "duplicati-backups_default", "Ports": "", "RunningFor": "42 minutes ago", "Size": "0B", "State": "exited", "Status": "Exited (0) 40 minutes ago" } ``` In here, we can see the exit code `(0)` indicates this container exited successfully (I think 😅 ). Could we use this as an indicator that the status should be `active` still and not `exited` maybe? Another command you could use is `docker inspect wait_for_nfs_duplicati --format='{{.State.ExitCode}}'` which will output either `0` for successful exit or any other number for failed. But this would require iterating through all containers in a stack. Thanks!
Author
Owner

@spuder commented on GitHub (Aug 21, 2025):

I see there was a PR merged to address this on June 27th, I don't think it fixed it as I still observe this behavior in version: 1.5.0.

Image

Looking at docker hub I see that louislam/dockge hasn't been pushed since about March 2025.

@spuder commented on GitHub (Aug 21, 2025): I see there was a PR merged to address this on June 27th, I don't think it fixed it as I still observe this behavior in version: `1.5.0`. <img width="548" height="299" alt="Image" src="https://github.com/user-attachments/assets/88488ade-3b7e-4795-aee7-50c29ae92f8d" /> Looking at docker hub I see that [louislam/dockge](https://hub.docker.com/r/louislam/dockge/tags) hasn't been pushed since about March 2025.
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/dockge-louislam#211
No description provided.