Open prussell69 opened 11 months ago
Hi @prussell69 - This may be similar to discussion here: https://github.com/jasonacox/Powerwall-Dashboard/discussions/403#discussioncomment-7889865 - I'm just not sure why it would have changed. It sure sounds like a bug in Docker Desktop.
My situation is not the same as #403. I have other containers running just fine. The issue only happens when Powerwall-Dashboard is started automatically (e.g. reboot, P/W-D upgrade, Docker restart). Once it's running, it runs for months with no issues. I would think if it was a Docker issue, my other containers would do something similar. I have "Powerwall-Dashboard", "Teslamate", and "Echo speaks server" running on the main system, and "Powerwall-Dashboard", "Teslamate" on my backup system. This seems to only effect Powerwall-Dashboard. If theres a log file or other diagnostic info that would help, just let me know what I need to send you and I'll do it.
That's fair, thanks. Yes, please post the logs for the containers that stopped, specifically at the point they stopped.
Hi @prussell69 - I have just noticed the exact same issue on Windows 10 with WSL2 and Docker Desktop 4.26.1
After a restart only the pypowerwall container starts, with the other containers showing an exit code of 127.
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
366701fb6c17 telegraf:1.28.2 "/entrypoint.sh tele…" 8 minutes ago Exited (127) 6 minutes ago 8092/udp, 8125/udp, 8094/tcp telegraf
8355e939f6cf jasonacox/weather411:0.2.2 "python3 server.py" 8 minutes ago Exited (127) 6 minutes ago 0.0.0.0:8676->8676/tcp weather411
56b587eaa297 grafana/grafana:9.1.2-ubuntu "/run.sh" 8 minutes ago Exited (127) 6 minutes ago 3000/tcp, 0.0.0.0:9000->9000/tcp grafana
72cea9cb98cc jasonacox/pypowerwall:0.6.4t29 "python3 server.py" 8 minutes ago Up 6 minutes 0.0.0.0:8675->8675/tcp pypowerwall
547577fc5ee9 influxdb:1.8 "/entrypoint.sh infl…" 8 minutes ago Exited (127) 6 minutes ago 0.0.0.0:8086->8086/tcp influxdb
I also tried changing the restart policy to "always" and it makes no difference. Once Windows/Docker has been running for a short period starting them manually works fine though.
Investigating why pypowerwall container starts but none of the others do, I realised those that do not start have volume bind mounts, whereas pypowerwall does not.
It does seem to me like a Windows & Docker issue unfortunately. For some reason I believe when Docker Desktop is starting up and attempting to start containers, the link to the filesystem in Windows to mount the volumes must not be ready, and the containers will not start (and apparently disobey any restart policies).
This seems to be a bug introduced in a new version of Docker Desktop??!! (did you update your version perhaps? That would explain why it seemed to work previously, and now does not).
I had an old version of Docker Desktop installer, so I uninstalled 4.26.1 and installed the old version which was 4.24.2
It works perfectly from what I can tell - all containers start up on a reboot/restart, and I would assume therefore on upgrades as well.
I'd suggest roll back to an old version of Docker Desktop if you can.
I'd suggest roll back to an old version of Docker Desktop if you can.
Great detective work @mcbirse! I wonder if there is a way to report this bug to Docker?
Investigating why pypowerwall container starts but none of the others do, I realised those that do not start have volume bind mounts, whereas pypowerwall does not.
FWIW, this will soon change as we roll out the new pypowerwall with built in cloud mode (Tesla Owners API support) since it needs persistent storage for the token.
Thanks for figuring that out. I will attempt to roll-back my docker. Hopefully Docker will fiqure this out.
Looks like the new version of Docker, 4.26.1, seems to have corrected the issue. I will do some more testing to make sure.
Interesting @prussell69 - Let us know how you go as that was the version I was experiencing problems with still (4.26.1).
If it is working now, it may simply have been an uninstall/re-install was needed to fix the issue.
I think I'm seeing the same or a slightly different problem with Docker Desktop v4.30.0 on Windows.
Upon a Windows restart, powerwall-dashboard
would not automatically start.
EDIT: Based on my research it seems to be related to https://github.com/docker/for-win/issues/13985 and https://github.com/docker/for-win/issues/13947 which appears to be a Docker Desktop for Windows bug
EDIT: Based on my research it seems to be related to https://github.com/docker/for-win/issues/13985 and https://github.com/docker/for-win/issues/13947 which appears to be a Docker Desktop for Windows bug
Thanks for finding this @longzheng - Rather discouraging. Is there a way to run docker (or alternative) on Windows without Docker Desktop?
EDIT: Based on my research it seems to be related to docker/for-win#13985 and docker/for-win#13947 which appears to be a Docker Desktop for Windows bug
Thanks for finding this @longzheng - Rather discouraging. Is there a way to run docker (or alternative) on Windows without Docker Desktop?
In theory I could run without Docker Desktop using the instructions here but I have one other container I'm running with Docker Desktop so I prefer to keep for now.
I've just downgraded to 4.24.2 as recommended by https://github.com/docker/for-win/issues/13985#issuecomment-2040978147 and it works so I'll just stay on the older version for now.
After doing a lot more testing and debugging, I've narrowed the problem down to running compose-dash.sh
or docker compose up -d
within WSL if the compose file uses bind mounts with individual files which powerwall.yml
definitely does. https://github.com/jasonacox/Powerwall-Dashboard/blob/003811d24790445752a267c78e00764d20957bc5/powerwall.yml#L9-L10
Anyways, I've found another workaround which works with the latest version of Docker Desktop. Simply run docker compose
from within Windows so the bind mounts are using Windows paths.
For example from the directory, run cmd
and then run
docker compose -f powerwall.yml up -d
Or simply run compose-dash.sh
with something like Git Bash which runs in Windows.
(This assumes you're not using powerwall.extend.yml
which the compose-dash.sh
script supports.)
Great find @longzheng !
It will be interesting to see if docker can address this. In the meantime, is there a way we could better accommodate this in compose-dash.sh, like some conditional that adjusts based on being on WinOS?
Not that this helps, but I can confirm that there is no issue on restart with the Docker on WSL-2 without Docker Desktop linked to above.
I haven't checked back to see if developments since I wrote it up have removed the need for any of the setup steps (e.g. enabling preview features that might be built into WSL), but it just keeps working, comes up on host restarts as expected, and doesn't come with the overhead of Docker Desktop.
Problem When the computer, docker, or the Powerwall-Dashboard after an upgrade restarts, only the "Pypowerwall" container starts. The other containers don't start. They are: grafana influxdb weather411 telegraf
To Reproduce
Host System Windows 11 - Intel CPU Docker v4.26
This started on my main PC back a few weeks ago. Not sure of the PW-Dash version at the time. I can stop the container (with only pypowerwall running) inside docker and start it right back up and everything starts fine. My backup PC didn't seem to have this issue right away, so I thought it was isolated to the main PC. However, I updated the backup PC today to PW-Dash version 3.0.5, and it started to do the same thing. I looked at the powerwall.yml file and found everthing was set with: "restart: unless-stopped". I even triedto change it to always, but it didn't seem to help. I don't want to loose my data, or cause problems poking around not knowing what to properly do to fix it, so I'm hoping someone here can help.