Originally created by @parasiteoflife on GitHub (Feb 15, 2025).
Right now when we use Podman with Komodo and the system is rebooted (so no podman containers are up) and Komodo is started it doesn't auto start all the stacks that were running before the reboot even when they have restart: unless-stopped.
Please, implement a feature to auto-start these stacks on Komodo start-up.
Originally created by @parasiteoflife on GitHub (Feb 15, 2025).
Right now when we use Podman with Komodo and the system is rebooted (so no podman containers are up) and Komodo is started it doesn't auto start all the stacks that were running before the reboot even when they have `restart: unless-stopped`.
Please, implement a feature to auto-start these stacks on Komodo start-up.
@t40mas commented on GitHub (Feb 25, 2025):
Hey @parasiteoflife,
did you already fixed your problem?
Try `restart: always` instead.
https://github.com/containers/podman/issues/20418
I can confirm that using restart: alwaysand configuring the podman-restart systemd unit fixes this problem, i.e., podman stacks configured under komodo appropriately restart on host reboot.
For complete reference, here are my working compose.yaml and podman-restart.service
compose.yaml:
name: caddy
services:
caddy_reverse_proxy:
# Use the caddy:latest image from Docker Hub
image: caddy:latest
container_name: caddy_proxy
restart: always
cap_add:
- NET_ADMIN
# ports for Caddy
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
# Mount the host Caddyfile
- ./Caddyfile:/etc/caddy/Caddyfile
- ./data:/data
- ./config:/config
# Connect the Caddy container caddy_net
networks:
- caddy_net
whoami:
image: traefik/whoami:latest
container_name: whoami
restart: always
networks:
- caddy_net
networks:
# Docker network for Caddy
# This network is important. Any Application that you want to use Caddy reverse proxy must be connected to the same network as Caddy.
caddy_net:
podman-restart.service:
[Unit]Description=Podman Start All Containers With Restart Policy Set To AlwaysDocumentation=man:podman-start(1)StartLimitIntervalSec=0Wants=network-online.targetAfter=network-online.target[Service]Type=oneshotRemainAfterExit=trueEnvironment=LOGGING="--log-level=info"ExecStart=/usr/bin/podman $LOGGING start --all --filter restart-policy=alwaysExecStop=/bin/sh -c '/usr/bin/podman $LOGGING stop $(/usr/bin/podman container ls --filter restart-policy=always -q)'[Install]WantedBy=default.target
@reshen commented on GitHub (Apr 9, 2025):
I can confirm that using `restart: always` *and* configuring the podman-restart systemd unit fixes this problem, i.e., podman stacks configured under komodo appropriately restart on host reboot.
https://github.com/containers/podman/issues/20418#issuecomment-1848843913 explains how to configure `podman-restart.service` appropriately.
Thanks for all the work on Komodo, it's great!
For complete reference, here are my working `compose.yaml` and `podman-restart.service`
`compose.yaml`:
```docker-compose
name: caddy
services:
caddy_reverse_proxy:
# Use the caddy:latest image from Docker Hub
image: caddy:latest
container_name: caddy_proxy
restart: always
cap_add:
- NET_ADMIN
# ports for Caddy
ports:
- "80:80"
- "443:443"
- "443:443/udp"
volumes:
# Mount the host Caddyfile
- ./Caddyfile:/etc/caddy/Caddyfile
- ./data:/data
- ./config:/config
# Connect the Caddy container caddy_net
networks:
- caddy_net
whoami:
image: traefik/whoami:latest
container_name: whoami
restart: always
networks:
- caddy_net
networks:
# Docker network for Caddy
# This network is important. Any Application that you want to use Caddy reverse proxy must be connected to the same network as Caddy.
caddy_net:
```
`podman-restart.service`:
```systemd
[Unit]
Description=Podman Start All Containers With Restart Policy Set To Always
Documentation=man:podman-start(1)
StartLimitIntervalSec=0
Wants=network-online.target
After=network-online.target
[Service]
Type=oneshot
RemainAfterExit=true
Environment=LOGGING="--log-level=info"
ExecStart=/usr/bin/podman $LOGGING start --all --filter restart-policy=always
ExecStop=/bin/sh -c '/usr/bin/podman $LOGGING stop $(/usr/bin/podman container ls --filter restart-policy=always -q)'
[Install]
WantedBy=default.target
```
@parasiteoflife commented on GitHub (May 16, 2025):
@t40mas I've followed the instructions in https://github.com/containers/podman/issues/20418#issuecomment-1848843913 and the containers do start automatically but komodo shows "UNKNOWN" for all the stacks now, the only action available for them is "Pull Images".
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @parasiteoflife on GitHub (Feb 15, 2025).
Right now when we use Podman with Komodo and the system is rebooted (so no podman containers are up) and Komodo is started it doesn't auto start all the stacks that were running before the reboot even when they have
restart: unless-stopped.Please, implement a feature to auto-start these stacks on Komodo start-up.
@t40mas commented on GitHub (Feb 25, 2025):
Hey @parasiteoflife,
did you already fixed your problem?
Try
restart: alwaysinstead.https://github.com/containers/podman/issues/20418
@reshen commented on GitHub (Apr 9, 2025):
I can confirm that using
restart: alwaysand configuring the podman-restart systemd unit fixes this problem, i.e., podman stacks configured under komodo appropriately restart on host reboot.https://github.com/containers/podman/issues/20418#issuecomment-1848843913 explains how to configure
podman-restart.serviceappropriately.Thanks for all the work on Komodo, it's great!
For complete reference, here are my working
compose.yamlandpodman-restart.servicecompose.yaml:podman-restart.service:@parasiteoflife commented on GitHub (May 16, 2025):
@t40mas I've followed the instructions in https://github.com/containers/podman/issues/20418#issuecomment-1848843913 and the containers do start automatically but komodo shows "UNKNOWN" for all the stacks now, the only action available for them is "Pull Images".
@mbecker20 commented on GitHub (Aug 27, 2025):
It seems that the original issue has been solved, closing this one