Closed rlpowell closed 4 years ago
rlpowell
commented
4 years ago This seems like such a glaring issue that I'm left wondering if I'm holding it wrong? Like, how do other people running hassio with Docker on Linux perform a clean restart of everything?
rlpowell
commented
4 years ago I grabbed https://github.com/home-assistant/cli , and can thus confirm that "/root/go/bin/cli supervisor repair ", once I figured out my api token, did not fix it, although it did cause docker images to get downloaded; I still have only:
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a3ce358a1bc1 homeassistant/amd64-hassio-dns:1 "coredns -conf /conf…" 34 minutes ago Up 30 minutes hassio_dns
3297768c41e0 homeassistant/amd64-hassio-supervisor "/bin/entry.sh pytho…" 34 minutes ago Up 30 minutes hassio_supervisorreload also did not help.
pvizeli
commented
4 years ago yep, never adjust manual docker container managed by supervisor.
Use somethings like ha host reboot or ha host shutdown. But also the systemd will care that the supervisor is shutdown correctly. You can't shudown the supervisor manual, only if you want remove it from system. The local installed part on your host will prevent that and also care that he shutdown/startup correctly on boot.
This is no issue:
20-02-27 07:37:19 INFO (SyncWorker_2) [hassio.docker.interface] Attach to homeassistant/qemux86-64-homeassistant with version 0.106.0
20-02-27 07:37:20 INFO (SyncWorker_8) [hassio.docker.interface] Attach to hassioaddons/node-red-amd64 with version 6.1.0He correctly attach to the data on the host of this add-ons. The Supervisor work different as the local docker / compose system.
Like we write on every information channel: The Supervisor is not just a container.
Yes, the only way to fix that is with the ha supervisor repair command
After this is implemented, you have an CLI also with superviserd installations: https://github.com/home-assistant/hassio-installer/issues/54
rlpowell
commented
4 years ago I really must be badly confused about something, because most of what you said doesn't seem relevant to what's going on for me.
yep, never adjust manual docker container managed by supervisor.
Well, "sudo systemctl restart hassio-supervisor" didn't actually restart anything except the supervisor, so my options were limited.
Use somethings like
ha host rebootorha host shutdown.
I have no idea how to do that; there is no program named "ha" on my supervisor instance:
rlpowell@lebna> sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fed5b83755f7 hassioaddons/node-red-amd64:6.1.3 "/init" 7 hours ago Up 7 hours addon_a0d7b954_nodered
7c08bc814905 homeassistant/qemux86-64-homeassistant:0.106.0 "/bin/entry.sh pytho…" 2 days ago Up 11 hours homeassistant
a3ce358a1bc1 homeassistant/amd64-hassio-dns:1 "coredns -conf /conf…" 2 days ago Up 2 days hassio_dns
3297768c41e0 homeassistant/amd64-hassio-supervisor "/bin/entry.sh pytho…" 2 days ago Up 2 days hassio_supervisor
rlpowell@lebna> sudo docker exec -it 3297768c41e0 bash
bash-5.0# find / -name ha
bash-5.0#Are you talking about manually installing https://github.com/home-assistant/cli when you refer to the ha command?
...
According to the help for that script, "host reboot" means rebooting my Linux box. No, you don't get to reboot my server, sorry. It's doing several other things besides running hass.io
Why would rebooting my linux box be required just to get the homeassistant instance restarted?
But also: why would I need to download an extra script just to restart hass.io? That seems super weird.
But also the systemd will care that the supervisor is shutdown correctly.
No, it doesn't.
rlpowell@lebna> sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fed5b83755f7 hassioaddons/node-red-amd64:6.1.3 "/init" 7 hours ago Up 7 hours addon_a0d7b954_nodered
7c08bc814905 homeassistant/qemux86-64-homeassistant:0.106.0 "/bin/entry.sh pytho…" 2 days ago Up 11 hours homeassistant
a3ce358a1bc1 homeassistant/amd64-hassio-dns:1 "coredns -conf /conf…" 2 days ago Up 2 days hassio_dns
3297768c41e0 homeassistant/amd64-hassio-supervisor "/bin/entry.sh pytho…" 2 days ago Up 2 days hassio_supervisor
rlpowell@lebna> sudo systemctl stop hassio-supervisor
[sudo] password for rlpowell:
rlpowell@lebna> sudo docker ps -a
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
fed5b83755f7 hassioaddons/node-red-amd64:6.1.3 "/init" 7 hours ago Up 7 hours addon_a0d7b954_nodered
7c08bc814905 homeassistant/qemux86-64-homeassistant:0.106.0 "/bin/entry.sh pytho…" 2 days ago Up 11 hours homeassistant
a3ce358a1bc1 homeassistant/amd64-hassio-dns:1 "coredns -conf /conf…" 2 days ago Up 2 days hassio_dns
3297768c41e0 homeassistant/amd64-hassio-supervisor "/bin/entry.sh pytho…" 2 days ago Exited (0) 2 seconds ago hassio_supervisor
hassio-dns is still up, homeassistant is still up, node-red is still up.
If systemd was actually stopping or starting things cleanly, I wouldn't have opened this issue.
You can't shudown the supervisor manual, only if you want remove it from system. The local installed part on your host will prevent that and also care that he shutdown/startup correctly on boot.
This is no issue:
20-02-27 07:37:19 INFO (SyncWorker_2) [hassio.docker.interface] Attach to homeassistant/qemux86-64-homeassistant with version 0.106.0 20-02-27 07:37:20 INFO (SyncWorker_8) [hassio.docker.interface] Attach to hassioaddons/node-red-amd64 with version 6.1.0He correctly attach to the data on the host of this add-ons. The Supervisor work different as the local docker / compose system.
As I said, I could be confused, but my point here was that it's attaching to an instance that did not exist. There was no homeassistant instance running. But the supervisor was perfectly content to claim to be attaching to an unstarted instance. It seems like that's a bug, and that if the homeassistant instance isn't running, the supervisor should notice that when it tries to attach, and turn it on.
Even if it's not going to self-repair in this case, shouldn't it at least generate an error? "Oh hey I tried to attach to this instance but it's down"?
Like we write on every information channel: The Supervisor is not just a container.
I mean, that was pretty obvious from the fact that it requires dbus and /var/run/docker.sock to function.
I understand that the supervisor is managing the other instances. My point is that it's not doing it very well in the case where an instance is down. And that it doesn't shut down the other instances when systemd tells it to shutdown.
Yes, the only way to fix that is with the
ha supervisor repaircommand
So, again assuming that you're talking about manually installing https://github.com/home-assistant/cli when you refer to the ha command, that didn't actually work.
"/root/go/bin/cli supervisor repair" worked (the command ran, and a bunch of output was produced in the logs, but it didn't actually start the homeassistant instance. Nor did "supervisor reload".
What actually worked was "core start".
After this is implemented, you have an CLI also with superviserd installations: home-assistant/hassio-installer#54
As andygrunwald said, that issue doesn't really explain what the goal is. Is that issue why I don't have the "ha" command?
I'm new to this project, but I'm perfectly willing to help out; if you want to provide (a lot) more detail in that issue, I'd be happy to take a crack at it.
rlpowell
commented
4 years ago I can confirm that "ha host shutdown" does, in fact, shutdown my entire Linux box (I had reason to shut it down anyway so it was worth a try). This is very very much not what I ever want, but I guess hassio really expects to be in charge of the whole machine.
That's kind of exactly the opposite of the point of using docker, though.
yozik04
commented
4 years ago I can confirm that there is something wrong with supervisor.
Yesterday I have installed a new version of docker. That means docker service restart.
amd64-hassio-supervisor container started, then started amd64-hassio-audio and amd64-hassio-dns. But homeassistant and plugins did not start.
brnhffmnn
commented
4 years ago What's the workaround here -- reboot the whole system?
rlpowell
commented
4 years ago I certainly never found any other way to do it besides rebooting the entire docker host; I eventually ended up moving from "run hassio on docker on my server" to "run hassio in a VM on my server", because hassio clearly wants to have complete control of the host it's running on, and giving it a VM solves that problem well enough. I actually wrote a bunch of scripts and so on to basically fully automate that; writeup is at https://github.com/rlpowell/hassio-vm
rct
commented
4 years ago I've been struggling with what I think is the same problem with perhaps a few different details.
Doing a cold boot, everything starts fine.
If I have to shut everything down to some maintenance, like upgrade docker, file system maintenance, etc., systemctl start hassio-supervisor does not restart homeassistant or the ssh add-on.
So there is no way to do any ha commands.
The supervisor will restart hassio-audio and hassio-dns, but it doesn't restart homeassistant or the community ssh add-on. (I haven't tested with the official ssh add-on).
I have tried to install the ha CLI on the host, however I don't think the supervisor's API port is exposed to the host by default. If homeassistant is running, I can set SUPERVISOR_ENDPOINT and then I can do ha commands on the host.
stale[bot]
commented
4 years ago This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Home Assistant release with the issue: This isn't an issue with home assistant as such; it's an issue with the hassio supervisor docker running on Linux. The supervisor image version is 201
Operating environment (HassOS/Generic): Linux (Fedora 31, specifically) using Docker. The initial setup was done with https://github.com/home-assistant/hassio-installer
Description of problem:
I had hassio running OK, but due to some problems I was having I wanted to restart everything. So I did a docker kill / docker rm of all the containers, and restarted. Specifically, I'm restarting with "sudo systemctl restart hassio-supervisor"; this uses the systemd configs installed by https://github.com/home-assistant/hassio-installer , but what it actually ends up running is /usr/sbin/hassio-supervisor , which looks like so:
This works fine. But. Here's the logs, and I'll show you the problem:
The problem is with these lines here:
The problem is that those docker instances are not, in fact, running!
There's nothing to attach to!
But the supervisor doesn't seem to notice this.
The only "fix" that I've found is to delete the docker images (not the docker containers, the images); something about having to download the images causes the system to also start the images.
Some things I've noticed in the code:
In /usr/src/hassio/hassio/homeassistant.py we have:
What I'm noticing is that the only error condition that that code catches is the "no image found" error condition; I suspect this is the source of the problem.
Also, I see that there's a "repair" function in /usr/src/hassio/hassio/homeassistant.py that looks like it forces an install, and the install functions cause the docker start to occur.
Is there a way to trigger the running of this "repair" function in a Linux Docker setup? I've exec'd into my docker instances and I don't seem to have this nifty "hassio" command everybody else has.