How to manually start hass.io using systemd commands

Hi
I run hass.io installed under a Ubuntu Linux OS and it all runs fine and all starts up at boot.
I am often in the situation where I may want to stop Home Assistant for a while do either hack files or do something where I want to home assistant to not discover something temporary.

Currently I do a

systemctl stop docker

And when I am done I reboot the machine and hass.io starts up again

I would like to avoid the reboot as it takes time.

I have tried to run the commands
´

systemctl start docker
systemctl start hassio-supervisor
systemctl start hassio-apparmor

But that does not start home assistant. The supervisor starts but hass.io does not and there is nothing in the log that gets added.

What is the correct sequence of commands you need to run to start home assistant running as hass.io under a Linux OS without booting?

What am I missing?

During boot it is systemd that starts docker and hass.io so it must be possible to do it this way. I’d like to do it exactly the same way that is does during boot.

I would like to know too. I did indeed notice the same behavior, if docker is stopped you do need to reboot to start hassio again.

sudo systemctl start hassio-supervisor.service

Will restart Hass.io and supervisor containers. It seems it doesn’t restart any other addons though so I have a HA script I can call to start those.

In general stopping docker is a bad idea. I usually just stop the home assistant container (using Portainer) and then restarting it when I’m finished.

It’s usually only when there’s a docker update I have to go through this rigmarole.

It does not work running sudo systemctl start hassio-supervisor.service
I have tried one or the other or both in any order. I end up with the supervisor running but Home Assistant is not started.

I know I can stop and start docker containers. But I want to understand how Home Assistant is started during boot and there is a missing bit of info.

You cannot stop Home Assistant with systemd - the process either ignores it or restarts again. The only systemd way I have found is to kill Docker.

Does anyone know how systemd starts hass.io at boot and why it fails doing it manually? That is my question.

It has worked for me with no problems.

What exactly worked?

I do this (I am root in a terminal so same as sudo)

systemctl stop docker
systemctl start hassio-supervisor.service

I get a supervisor running

But home assistant is NOT started. It never comes up. And nothing in the home assistant log.

Running that command for me starts supervisor container, homeassistant container and dns container. (Just the hassio-supervisor.service)

Before I found out you could do that I just used to use Portainer to start those containers manually.

It may be you need to wait a little depending on your hardware.

Anyway, just last week after a docker update I used it and it worked fine. That was when I made the script to start every other HA addon container as if I start those via Portainer it they stop immediately.

You could install Portainer and then stop/start any container you wish from the Web UI

docker volume create portainer_data
docker run -d -p 9000:9000 -v /var/run/docker.sock:/var/run/docker.sock -v portainer_data:/data portainer/portainer

@kanga_who It is kind of you to suggest other ways to start Home Assistant.
But my question is really how systemd does it during boot. It annoys me that I do not fully understand how HA comes up. It takes 15 seconds extra to just boot.
My annoyance is that I do not understand how things work and how to manually do the same.

@DavidFW1960 there is obviously something different in your installation but you also have much more docker based stuff and you said yourself that it does not start all the other hass.io addons.

There is an extra step that happens during boot - or maybe the systemd scripts assumes that they are executed from a particular current working directory?

Here are some process listings after a manual start

root@homeassistant:~# ps -ef | grep hass
root      9226     1  0 09:29 ?        00:00:00 /bin/sh /usr/sbin/hassio-supervisor
root      9253  9226  0 09:29 ?        00:00:00 docker start --attach hassio_supervisor
root      9319  9289  3 09:29 ?        00:00:01 /usr/local/bin/python3 -m hassio
root      9905  7694  0 09:30 pts/0    00:00:00 grep --color=auto hass
root@homeassistant:~# ps -ef | grep docker
root      9020     1  0 09:29 ?        00:00:00 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
root      9253  9226  0 09:29 ?        00:00:00 docker start --attach hassio_supervisor
root      9289  1329  0 09:29 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/1f25adfd6a0920bb4d9eeb06e070b730d4e1e81fe8d2c5483f367055287993ef -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      9558  1329  0 09:29 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/3959aedbe184fe09e550a5dc0464a66afbafc3ed557d2d427c427ecfb14eb2ed -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      9590  9558  0 09:29 ?        00:00:00 /sbin/docker-init -- coredns -conf /config/corefile
root      9982  7694  0 09:30 pts/0    00:00:00 grep --color=auto docker

And this is how it looks like after a boot where HA has started up correctly

We can see much more is started up.

ps -ef | grep hass
root      2243     1  0 09:36 ?        00:00:00 /bin/sh /usr/sbin/hassio-supervisor
root      2323  2243  0 09:36 ?        00:00:00 docker start --attach hassio_supervisor
root      2387  2360  3 09:36 ?        00:00:02 /usr/local/bin/python3 -m hassio
root      5626  5621  0 09:37 ?        00:00:00 ttyd --reconnect 30 -d1 -i /var/run/ttyd.sock tmux -u new -A -s hassio zsh
root      6425  6395  5 09:37 ?        00:00:00 /usr/local/bin/python /usr/local/bin/hass-configurator /etc/configurator.conf
root      6476  2612  0 09:37 pts/0    00:00:00 grep --color=auto hass
root@homeassistant:~# ps -ef | grep docker
root      1573     1  1 09:36 ?        00:00:01 /usr/bin/dockerd -H fd:// --containerd=/run/containerd/containerd.sock
root      2323  2243  0 09:36 ?        00:00:00 docker start --attach hassio_supervisor
root      2360  1205  0 09:36 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/1f25adfd6a0920bb4d9eeb06e070b730d4e1e81fe8d2c5483f367055287993ef -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      2713  1205  0 09:36 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/d673d1c76fd2494025b0f2681489165482be508b87158f2c84a633ff990cca8b -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      2743  2713  0 09:36 ?        00:00:00 /sbin/docker-init -- coredns -conf /config/corefile
root      2897  1573  0 09:36 ?        00:00:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 6220 -container-ip 172.30.33.0 -container-port 6220
root      2914  1205  0 09:36 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/35990dacb8533b81084768a486bf8c5b476e3829e27d4bfd9c5d0b23b71c72e4 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      2936  1205  0 09:36 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/8545fbda406b1f2be8af46bcd8415a0f336ad8487e5bbf0103ac56a063a52e1f -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      2949  2914  0 09:36 ?        00:00:00 /sbin/docker-init -- /init
root      2966  1573  0 09:36 ?        00:00:00 /usr/bin/docker-proxy -proto tcp -host-ip 0.0.0.0 -host-port 8321 -container-ip 172.30.33.2 -container-port 8321
root      2985  1205  0 09:36 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/9cc007c2dd701aedc9d8e8b896911bb957fd929ed27ea4a0878956eb18fe2a39 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      3017  2936  0 09:36 ?        00:00:00 /sbin/docker-init -- /init
root      3033  2985  0 09:36 ?        00:00:00 /sbin/docker-init -- /init
root      3039  1205  0 09:36 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/dd180b48a3859a36b197b751d55d3db19d036c1b509ffa6dd2c3e206ae1e4bce -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      3077  3039  0 09:36 ?        00:00:00 /sbin/docker-init -- /init
root      5005  1205  0 09:37 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/ee1ceee68f16a7086eefa8b2237e47c223c971907e32a16d581a494a4ad190ef -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      5042  5005  0 09:37 ?        00:00:00 /sbin/docker-init -- /bin/entry.sh python3 -m homeassistant --config /config
root      6238  1205  0 09:37 ?        00:00:00 containerd-shim -namespace moby -workdir /var/lib/containerd/io.containerd.runtime.v1.linux/moby/0fcda5667ca3c3c3beaf9a1f0d4c7726089f940fc4252a9418575ad3ce7d49d4 -address /run/containerd/containerd.sock -containerd-binary /usr/bin/containerd -runtime-root /var/run/docker/runtime-runc
root      6296  6238  0 09:37 ?        00:00:00 /sbin/docker-init -- /run.sh
root      6478  2612  0 09:37 pts/0    00:00:00 grep --color=auto docker

Yeah I don’t understand why either. All my non hassio containers come up by themselves after I do a docker update… all of them are restart-unless stopped via docker-compose but hass.io is a law unto itself. I agree they should restart but they don’t without a reboot or in my case anyway running that command.