-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not everything is starting up on Windows 11 machines #409
Comments
Hi @prussell69 - This may be similar to discussion here: #403 (comment) - 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. |
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.
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). I found a solution though!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. |
Great detective work @mcbirse! I wonder if there is a way to report this bug to Docker?
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, 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 docker/for-win#13985 (comment) 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 Powerwall-Dashboard/powerwall.yml Lines 9 to 10 in 003811d
Anyways, I've found another workaround which works with the latest version of Docker Desktop. Simply run For example from the directory, run
Or simply run (This assumes you're not using |
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.
The text was updated successfully, but these errors were encountered: