Autostart using systemd

aa755 · February 17, 2021, 6:55pm

if you have a component that accesses network at startup, After=network-online.target 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: https://unix.stackexchange.com/a/356189/62292
My systemd file is:

[Unit]
Description=Home Assistant
After=NetworkManager-wait-online.service
Requires=NetworkManager-wait-online.service

[Service]
Type=simple
User=%i
WorkingDirectory=/home/%i/.homeassistant
ExecStart=/srv/homeassistant/bin/hass -c "/home/%i/.homeassistant"

[Install]

More info about my machine (standard Manjaro KDE)

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

MickPB · February 28, 2021, 9:54pm

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]
Description=Hass.io supervisor
Requires=docker.service
After=docker.service dbus.socket

[Service]
Type=simple
Restart=always
RestartSec=5s

ExecStartPre=-/usr/bin/docker stop hassio_supervisor
ExecStart=/usr/sbin/hassio-supervisor
ExecStop=-/usr/bin/docker stop hassio_supervisor


[Install]
WantedBy=multi-user.target

and tried
sudo systemctl daemon-reload
sudo systemctl restart

and
curl -Lo installer.sh https://raw.githubusercontent.com/home-assistant/supervised-installer/master/installer.sh
bash installer.sh

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

core-2021.2.3
supervisor-2021.02.11
Docker 20.10.4
Raspbian GNU/Linux 10

TIA

filgr8 · March 1, 2021, 5:35pm

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

and

sudo systemctl --system daemon-reload

MickPB · March 1, 2021, 6:17pm

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

filgr8 · March 1, 2021, 7:04pm

Did you put hashtag in front like iI did?

Hashtag “commenting out” help me with reboot

filgr8 · March 1, 2021, 7:07pm

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

belov-ve · March 2, 2021, 3:42pm

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:

MickPB · March 3, 2021, 1:47am

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

MickPB · March 3, 2021, 2:44am

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

matbee · December 9, 2021, 8:41am

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?

dony1971 · December 23, 2021, 10:27pm

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?

Maschbaer · January 29, 2022, 10:42am

Hello,

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:

[Unit]
Description=Home Assistant Docker
Requires=docker.service
After=docker.service

[Service]
Restart=always
RestartSec=3
ExecStart=/usr/bin/docker start -a home-assistant
ExecStartPre=/bin/sleep 40
ExecStop=/usr/bin/docker stop -t 2 home-assistant

[Install]
WantedBy=mutli-user.target

P.s.
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?
Jan

Roumano · February 3, 2022, 7:53am

Hi,
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 :

RestartForceExitStatus=100

More information on the issue created :

github.com/home-assistant/core

Failed to restart Home Assistant with the Gui with the 2022.2.0 version

opened 09:40PM - 02 Feb 22 UTC

closed 05:24AM - 03 Feb 22 UTC

roumano

### The problem After upgrading to `2022.2.0`, if i restart the home assistant …with the gui ( with url http://.../config/server_control ) It's crashing and never started From a ssh command, i can start the service without any issue ### What version of Home Assistant Core has the issue? core-2022.2.0 ### What was the last working version of Home Assistant Core? core-2021.12.10 ### What type of installation are you running? Home Assistant Core ### Integration causing the issue _No response_ ### Link to integration documentation on our website _No response_ ### Example YAML snippet ```yaml I have enable the full debug information but it not providing information where it's crashing ``` ### Anything in the logs that might be useful for us? ```txt I have enable the full debug information but it not providing information where it's crashing févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event homeassistant_final_write[L]> févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (MainThread) [custom_components.hacs] HacsTask<store_hacs_data> Executing task févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (MainThread) [custom_components.hacs] Saving data févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (SyncWorker_4) [homeassistant.helpers.storage] Writing data for trace.saved_traces to /data/homeassistant/.homeassistant/.storage/trace.saved_traces févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (SyncWorker_6) [homeassistant.helpers.storage] Writing data for http to /data/homeassistant/.homeassistant/.storage/http févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (SyncWorker_11) [homeassistant.helpers.storage] Writing data for core.restore_state to /data/homeassistant/.homeassistant/.storage/core.restore_state févr. 02 22:23:37 rasp hass[11163]: 2022-02-02 22:23:37 DEBUG (MainThread) [custom_components.hacs] Did not store data for 'hacs.hacs'. Content did not change févr. 02 22:23:38 rasp hass[11163]: 2022-02-02 22:23:38 DEBUG (MainThread) [custom_components.hacs] Did not store data for 'hacs.repositories'. Content did not change févr. 02 22:23:38 rasp hass[11163]: 2022-02-02 22:23:38 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event hacs/repository[L]> févr. 02 22:23:38 rasp hass[11163]: 2022-02-02 22:23:38 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event hacs/config[L]> févr. 02 22:23:38 rasp hass[11163]: 2022-02-02 22:23:38 DEBUG (MainThread) [custom_components.hacs] HacsTask<store_hacs_data> took 0.196 seconds to complete févr. 02 22:23:38 rasp hass[11163]: 2022-02-02 22:23:38 DEBUG (MainThread) [homeassistant.core] Bus:Handling <Event homeassistant_close[L]> févr. 02 22:23:41 rasp systemd[1]: [email protected]: Main process exited, code=exited, status=100/n/a févr. 02 22:23:41 rasp systemd[1]: [email protected]: Failed with result 'exit-code'. févr. 02 22:23:41 rasp systemd[1]: home-assista[email protected]: Consumed 49.632s CPU time. ``` ``` ### Additional information _No response_

HelpITru · February 6, 2022, 2:58pm

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

joeyparis · February 14, 2022, 3:48am

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

systemctl enable systemd-networkd-wait-online.service

Then replaced After=network-online.target with:

[Unit]
...
After=systemd-networkd-wait-online.service
Requires=systemd-networkd-wait-online.service

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

TallGayDani · March 13, 2022, 12:43pm

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

planetmarshall · March 24, 2022, 12:02pm

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

damiano94 · July 5, 2023, 10:52pm

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

glyndon · July 5, 2023, 11:14pm

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:

#!/bin/bash
. /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!

dannysauer · August 20, 2023, 4:27am

People probably shouldn’t directly edit systemd units in specific paths - it’s easy to make an error. 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.