Custom Component: systemd (Run HA as a systemd notify daemon, with watchdog support!)

Yes, I noticed that too when testing just now.

I think I’ve figured out an easy way to fix your issue (assuming it’s problem #2), basically listening for the restart event (like you suggested). I’m testing it now.

Not sure if the call service intercept will work. I added this

shell_command:
  send_systemd_notify: /usr/bin/systemd-notify STOPPING=1

Then i called the service in ha, i can see status shows

deactivating (stop-sigterm)

A bit under

Status: "Home Assistant is running." Which is correct since i just send only STOPPING, then call homeassistant.restart and same happens again

For this you have to setup

NotifyAccess=all

A dirty workaround is just to disable the STOPPING notification, just use the STATUS messages

Sorry for the delay, holiday weekend here in the US and all.

It turns out it’s not problem #2. After some additional testing combined with your experimentation I believe I’ve figured out what’s going on. Essentially, we’re catching the ha.stop event and sending a STOPPING notification to systemd. The problem is, since we’re restarting HA it never actually stops; systemd sits there waiting for it to stop until the timeout is reached. This is confirmed by the fact that disabling the ha.stop listener fixes the problem.

So, I think we need to listen for the ha.restart event and, if detected, set a flag. We’ll have the ha.stop listener function check that flag to determine if it should send the STOPPING notification or not.

Alternatively we can have the ha.restart listener simply disable the ha.stop listener.

I’m working on this now.

I was looking at core.py among other files also. I didn’t not see an event called restart, I did however see an event fired after stop called EVENT_HOMEASSSISTANT_CLOSE but I couldn’t catch it with the listener, I was thinking this event was related to full stop.

Hi thanks very much for this watchdog, I’m going to try it out. I’m currently using the systemd instructions that are in the docs here:

I have a few quick questions when using this component, is the best way to restart HA to simply run:

  • sudo systemctl restart hass.service

Also when upgrading HA to a different version, I guess this service should be stopped first? Is something like this OK:

sudo systemctl stop hass.service
cd homeassistant
source bin/activate
python3 -m pip install --upgrade homeassistant
deactivate
sudo systemctl start hass.service

Yes, until I get a chance to implement support for HA’s native restart ability the best way is to simple issue a systemctl restart *ha-service*.service.

For upgrading HA, after you’ve stopped it and performed the upgrade, I’d go into your HA directory and start it by hand and let it load up fully once:

sudo systemctl stop *ha-service*.service
cd *ha-dir*
source bin/activate.sh
sudo -u *ha-user* pip3 install —upgrade homeassistant
sudo -u *ha-user* hass -c /srv/hass
[Home Assistant Starts...]
[Home Assistant Finishes Loading...]
<CTRL-C>
[Home Assistant Stops...]
sudo systemctl start *ha-service*.service

Obviously change the stuff in asterisk to match your installation. The reason I do this is because after an upgrade HA typically updates various packages during startup, which can extend the startup tIme and cause systemd to kill and restart it. Alternatively you could do a systemctl edit —full *ha-service*.service and extend the watchdog and startup timers to 5+ minutes. This should give HA enough time to update itself before HA kills it.

Let me know if you need more help. :slight_smile:

1 Like

Thanks that’s great, I think I’ll try the start it by hand method next time I need to do a HA update, they can take quite a while sometimes.

I’ve only been running the watchdog for 1 day, so far so good. :slight_smile:

Hey guys, so I’ve got a new version coming up here soon. I’ve added support for HA’s native restart functionality. It’s not super elegant, but it works! It also requires a watchdog timeout value of at least 60 seconds, but that shouldn’t be an issue for most people. (Basically when we see a restart request come through we don’t send the STOPPING message to systemd and we immediately pet the watchdog. A 60 second watchdog timeout value should be long enough for HA to stop, start and reactivate our plugin. If you have a ton of components or devices in HA, or have a very slow system, it might require an even longer timeout value.)

Like I said, not the most elegant solution, but it functions.

3 Likes

when do you think you’re going to submit the component to main ha?

Hi, I have a timeout value set to 5 mins as sometimes it takes a while to load HA when it’s just been updated to a later version.

However usually my HA takes less than 1 min to startup. :slight_smile:

Hi @timothybrown
May be I am completly off topic, should I use this custom component to start - stop - query status of others systemd daemons?
I want to have a switch in HA to turn on and off httpd, pure-ftp and whatever has a systemctl .service registered.
Suggestion?

Thanks in advance.