[Help] Docker Engine 29.4.0.007 – race in cold-boot autostart logic leaves containers permanently at restart policy "no"
Posted: 18 Oct 2026, 07:49
Hello,
I'd like to report a bug in the Docker Engine app's cold-boot logic. Full disclosure: the diagnosis below and this report were written with the help of Claude (Anthropic's AI assistant), based on my own logs and the app's init script.
Environment
- Model: [F6-425]
- TOS: [TOS 7.0.1298]
- Docker Engine: 29.4.0.007
- ~31 containers deployed with Docker Compose, all with "restart: unless-stopped"
Symptom
After a restart, only 7 of 31 containers came back. The other 24 had their restart policy set to "no" (docker inspect -> HostConfig.RestartPolicy.Name = "no"), although their compose files say unless-stopped. The 7 that did start now show "always" instead of unless-stopped.
Analysis
In /Volume2/@apps/DockerEngine/init.d/service, on cold boot:
- disable_container_autostart() rewrites every hostconfig.json from always/unless-stopped to "no" and saves the container list in /tmp/docker_autostart_containers;
- restore_container_autostart() later runs "docker update --restart=always" and "docker start" on that list.
Excerpt from /Volume2/@apps/DockerEngine/conf/log.txt (full log attached):
2026-10-18 00:27:16 - Disabled autostart for 31 container(s).
2026-10-18 00:27:45 - Restoring autostart and starting container ... (several)
2026-10-18 00:27:46 - Found existing dockerd (pid=9375) started without cold-boot protections, stopping it to restart properly.
2026-10-18 00:27:49 - Stopped existing dockerd, proceeding with cold-boot sequence.
2026-10-18 00:27:50 - Disabled autostart for 7 container(s).
2026-10-18 00:28:13 - Restored autostart for 7 container(s), skipped 0 due to mount validation.
A second run of the script started while the first one was still restoring containers. It killed the running dockerd (all running containers exited with code 255), rebuilt the autostart list from the containers still at always/unless-stopped at that moment (only the 7 already restored), and overwrote /tmp/docker_autostart_containers. The other 24 containers stay at "no" permanently: every later boot only sees and restores those 7 (confirmed by the following boots in the log). Before this event, the log shows clean cycles (e.g. 27/27 restored).
Suggested fixes
1. Prevent concurrent runs of the service script (e.g. flock on a lock file).
2. Keep the autostart list on persistent storage instead of /tmp, and never overwrite a list that has not been fully restored yet.
3. Restore each container's original restart policy (unless-stopped vs always) instead of forcing "always".
Note: the workaround suggested on the forum (switching to "always", see viewtopic.php?t=9883) does not protect against this issue, since containers end up at "no" regardless of their original policy.
Current workaround on my side: re-applying the policy with "docker update --restart unless-stopped" and starting the containers, plus a boot-time scheduled task as a safety net.
Best regards.
I'd like to report a bug in the Docker Engine app's cold-boot logic. Full disclosure: the diagnosis below and this report were written with the help of Claude (Anthropic's AI assistant), based on my own logs and the app's init script.
Environment
- Model: [F6-425]
- TOS: [TOS 7.0.1298]
- Docker Engine: 29.4.0.007
- ~31 containers deployed with Docker Compose, all with "restart: unless-stopped"
Symptom
After a restart, only 7 of 31 containers came back. The other 24 had their restart policy set to "no" (docker inspect -> HostConfig.RestartPolicy.Name = "no"), although their compose files say unless-stopped. The 7 that did start now show "always" instead of unless-stopped.
Analysis
In /Volume2/@apps/DockerEngine/init.d/service, on cold boot:
- disable_container_autostart() rewrites every hostconfig.json from always/unless-stopped to "no" and saves the container list in /tmp/docker_autostart_containers;
- restore_container_autostart() later runs "docker update --restart=always" and "docker start" on that list.
Excerpt from /Volume2/@apps/DockerEngine/conf/log.txt (full log attached):
2026-10-18 00:27:16 - Disabled autostart for 31 container(s).
2026-10-18 00:27:45 - Restoring autostart and starting container ... (several)
2026-10-18 00:27:46 - Found existing dockerd (pid=9375) started without cold-boot protections, stopping it to restart properly.
2026-10-18 00:27:49 - Stopped existing dockerd, proceeding with cold-boot sequence.
2026-10-18 00:27:50 - Disabled autostart for 7 container(s).
2026-10-18 00:28:13 - Restored autostart for 7 container(s), skipped 0 due to mount validation.
A second run of the script started while the first one was still restoring containers. It killed the running dockerd (all running containers exited with code 255), rebuilt the autostart list from the containers still at always/unless-stopped at that moment (only the 7 already restored), and overwrote /tmp/docker_autostart_containers. The other 24 containers stay at "no" permanently: every later boot only sees and restores those 7 (confirmed by the following boots in the log). Before this event, the log shows clean cycles (e.g. 27/27 restored).
Suggested fixes
1. Prevent concurrent runs of the service script (e.g. flock on a lock file).
2. Keep the autostart list on persistent storage instead of /tmp, and never overwrite a list that has not been fully restored yet.
3. Restore each container's original restart policy (unless-stopped vs always) instead of forcing "always".
Note: the workaround suggested on the forum (switching to "always", see viewtopic.php?t=9883) does not protect against this issue, since containers end up at "no" regardless of their original policy.
Current workaround on my side: re-applying the policy with "docker update --restart unless-stopped" and starting the containers, plus a boot-time scheduled task as a safety net.
Best regards.