Autostart using systemd

if you have a component that accesses network at startup, may not be sufficient. In my case, dns resolution was failing for my component when it accessed network at startup, probably because systemd was starting hass too early.
The following helped me:
My systemd file is:

Description=Home Assistant

ExecStart=/srv/homeassistant/bin/hass -c "/home/%i/.homeassistant"


More info about my machine (standard Manjaro KDE)

[xxxxx@computer ~]$ systemctl is-enabled NetworkManager-wait-online.service systemd-networkd-wait-online.service
1 Like

Help please. After some system changes I find that I cannot get the Supervisor container to start after a reboot.

It starts fine if I trigger it manually.

I’ve checked /etc/systemd/system/hassio-supervisor.service

[Unit] supervisor
After=docker.service dbus.socket


ExecStartPre=-/usr/bin/docker stop hassio_supervisor
ExecStop=-/usr/bin/docker stop hassio_supervisor


and tried
sudo systemctl daemon-reload
sudo systemctl restart

curl -Lo

But still end up having to start the supervisor container manually. I see other posts that indicate some portion of the install might need to be re issued but have not been able to pick that apart and apply it to the current HA. My enviro

Docker 20.10.4
Raspbian GNU/Linux 10


1 Like

editing this file helped me with manual restarting HA

sudo nano /etc/systemd/system/hassio-supervisor.service

and editing this line to:
#ExecStartPre=-/usr/bin/docker stop hassio_supervisor


sudo systemctl --system daemon-reload

I have that in there already. Thanks though

Funny coincidence, Same time you sent that - I was just watching the system restart and for a bit Supervisor was running and then fell over. I can restart the container and all is well>?>? Maybe there is another sequence issue. I dunno. Very frustrate. This all started with trying out TailScaled in place of Wireguard

Did you put hashtag in front like iI did?

Hashtag “commenting out” help me with reboot

What triggered my problem with HA not starting up after reboot is Ubuntu apt upgrade/update

1 Like

Same problem after Raspbian update (PI 3). In hassio-supervisor service container don’t start with key --attach (in file /usr/sbin/hassio-supervisor last line with docker start --attach hassio_supervisor).
Docker version 20.10.4
Downgrading docker-ce to 19.03.15 did not help.
Everything worked on docker version 20.10.4 after reinstalling the Home Assistant Supervised:

Thanks for pointing that out - iPhone doesn’t make up for me not wearing my glasses!
I’ll give that a try.

After trying it - No joy. I tried it a second time after re-running the installer as well

Thanks all for the help.

I tried commenting the line and no joy. I tried re-running the install script no luck. Re-commented the line and no luck. Finally read the log file and found a complaint regarding HACS having an invalid token. I tried removing and reloading HACS and get the ever helpful “unknown error” when re-installing.

I’ve made too many mistakes trying changes and doing things to the system and now doubt that I can ever trust it again. At this point I am still open for ideas but as soon as I get time I guess I will try rebuilding the system and then recopying to the SSD.
If anyone has a guide to do that - I’d really appreciate a link
Thanks again

The systemd setup works fine for me, however the audio messages played with aplay only work when started from the terminal.
Here’s the test command: /usr/bin/aplay /usr/share/sounds/alsa/Front_Center.wav
It seems that aplay doesn’t have enough permissions.

How can investigate further?

I have problem also executing hass in virtualenv via systemd
Python SSL has ssl.SSLCertVerificationError via systemd
(ssl.SSLCertVerificationError: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate)
Anybody know why?


I am running HA das Docker Container. I would like to start it via systemd at the start up of my Pi. It tried the example above but it does not work for me. Instead I have the following service file which works to start the HA Docker container manually by sudo systemctl start home-assistant-docker.service

The code of my service file is as follows:

Description=Home Assistant Docker

ExecStart=/usr/bin/docker start -a home-assistant
ExecStartPre=/bin/sleep 40
ExecStop=/usr/bin/docker stop -t 2 home-assistant


It setup a sleep of 40, because I need to wait until my Homematic CCU, which is running on the same Pi, is loaded, because HA reads some sensor data from the HM CCU.

However, even after doing sudo systemctl --system daemon-reload and sudo systemctl enable home-assistant-docker.service the HA Docker Container does not start when I reboot my Pi.

Any suggestions what I do wrong?

It’s a breaking changed on the 2022.02.0 (not listed yet) with systemd.

Need to add this on a core home assistant systemd configuration :


More information on the issue created :

1 Like

does not work in HASS OS, it is generally impossible to run a python script in the background there.

I found my solution to getting this working again here. I had to run

systemctl enable systemd-networkd-wait-online.service

Then replaced with:


From my understanding, Requires being a stricter version of Wants/WantedBy which is critical to running this on boot.

1 Like

Hi, so I followed the instructions to a T, but fedora is throwing errors?
Here’s what’s come up:

  • Started Home Assistant.
  • [email protected]: Failed to locate executable /srv/homeassistant/bin/hass: No such file or directory
  • [email protected]: Failed at step EXEC spawning /srv/homeassistant/bin/hass: No such file or directory
  • [email protected]: Main process exited, code=exited, status=203/EXEC
  • home-[email protected]: Failed with result ‘exit-code’.

I checked HASS and it’s definitely locatable, what could I be doing wrong? TIA :slight_smile:

Very helpful thanks. Worth noting that if you are installing home assistant from scratch (eg using ansible or some other method to automate an install), the .homeassistant folder does not exist, and starting the service will fail.

The solution is just to create it before starting the service.

mkdir /home/YOUR_USER/.homeassistant
sudo systemctl start home-assistant@YOUR_USER

So when hass is started using systemd, there’s no need to enable virtualenv first?

You don’t need to have activated the venv for yourself, but whatever systemd calls, should do so for itself.
I’ve used a venv for many years to run HA, and have always launched it using a systemd .desktop file, which calls a shell script, the first two lines of which are:

. /srv/homeassistant/bin/activate

So even though systemd starts the HA process through the script, the script/process still sets itself up in the venv, else who knows what python, packages, and environment HA might be inheriting!

People probably shouldn’t directly edit systemd units in specific paths - it’s easy to make an error. :slight_smile: To create a new one:
systemctl edit --force --full [email protected]

To edit the main unit file:
systemctl edit --full [email protected]

To add an override:
systemctl edit [email protected]

There’s no need to remember which location is for user units or system units or for packager units or for overrides, etc. Run it as a user, get a user unit. Run it as root, get a local system unit. It’ll even use whatever you have set in $EDITOR or $VISUAL, so vim or nano or whatever. That also automatically does the daemon-reload afterwards if necessary, so no forgetting to run that command. I really wish this was better publicized; it’s sooo much more convenient.