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?
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
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 :
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 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.
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 
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:
#!/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!
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.
3 Likes