[work around] At shutdown/reboot the systemd Hassio-Supervisor service stop job hangs and times out after 3 minutes

Did an install on ubuntu 18.04 per

Installed is a systemd service hassio-supervisor

[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

All seems to be working ok…but

During the system shutdown (ubuntu 18.04) it fires a stop job for hassio-supervisor systemd service which basically hangs and eventually times out after about 3 minutes and then the shutdown finishes.

If I do sudo systemctl stop hassio-supervisor from a terminal it seems to shutdown ok in a few seconds so

I am guessing that at shutdown that command from the service /usr/bin/docker stop hassio_supervisor
is hanging. All it is doing is stopping the container so not sure why this would hang.

Given the After=docker.service dbus.socket
it should do this before the docker service stops (systemd does order in reverse at shutdown).

I thought maybe the mounted partition that my containers are on was unmounting before and thus causing the hang but I added an After for that in the docker service to make sure. That did not cure this issue.

Anyone faced this? Have a solution?

I run this on a home server that has other missions and although it’s not fatal having the server take an extra 3 minutes to reboot is an issue.
`

Did you ever find a solution to this? I am having the same issue with Hass.io and a Debian 9.

Just another me too - I’m having the same issue.

Nope still haven’t come by a solution.

I do know that if before reboot if I do a

sudo systemctl stop hassio-supervisior

then reboot is not an issue. (no stop job)

So this tells me some service that hassio-supervisor needs to stop correctly is being killed before it.
As I mentioned I tried a few obvious things but no love.

In the meantime I have a reboot alias like this.

alias reboot='sudo systemctl stop hassio-supervisor && sudo systemctl reboot'

still doesn’t cover unplanned reboots nor reboot requests from other than me from the cli.

Glad to know it’s not just my particular issue (although it happens on both my dev machine and on my nas box). If one of the dev’s can maybe illuminate what other non-obvious services that hassio-supervisor or it’s dependents might depend on then we might track down the culprit.

My next move may be to just remove
ExecStop=/usr/bin/docker stop hassio_supervisor
from the unit file and so it won’t attempt to stop during shutdown and just be killed. Not sure if it really needs to do any special cleanup as running it manually seems to be almost instantaneous, besides power outages don’t give time for cleanup. Most caches/dbs these days are self repairing anyway.

Another issue to face its that it’s really hard to grab all the shutdown console output to get a clear picture of what shutdown when making it even harder to track this down.

YEA I have a work around

It doesn’t involve actually knowing which service that hassio-supervisor depends on to be still running when it shuts down. Instead I just make sure that hassio-supervisor is going to start after everything else.

That means using a systemd target that comes after multi-user

systemd seems to install such a target by default (at least on ubuntu 18+). No surprise it is called default.target

so here are some steps.

First look to see if the default.target exists.
ls -l /lib/systemd/system | grep default
> lrwxrwxrwx 1 root root 16 Jan 9 07:11 default.target -> graphical.target
cat /lib/systemd/system/default.target
the contents should look like this.

#  SPDX-License-Identifier: LGPL-2.1+
#
#  This file is part of systemd.
#
#  systemd is free software; you can redistribute it and/or modify it
#  under the terms of the GNU Lesser General Public License as published by
#  the Free Software Foundation; either version 2.1 of the License, or
#  (at your option) any later version.

[Unit]
Description=Graphical Interface
Documentation=man:systemd.special(7)
Requires=multi-user.target
Wants=display-manager.service
Conflicts=rescue.service rescue.target
After=multi-user.target rescue.service rescue.target display-manager.service
AllowIsolate=yes

the important thing is the Requires, After, and AllowIsolate. These force this target to load after multi-user which is where pretty much everything gets started…so after all the things that hassio-supervisor needs.

On the flip side at shutdown hassio-supervisor will run its stop job before everything else in multi-user target and thus not hang.

so assuming you have this default.target (which you may not, especially if you never installed any X stuff) then you need to edit the hassio-supervisor.service like this.

[Unit]
Description=Hass.io supervisor
Requires=docker.service
# After=docker.service dbus.socket mnt-docker.mount
After=multi-user.target

[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
WantedBy=default.target

then do a sudo systemctl daemon-reload
followed by a sudo systemctl restart
then try your reboot.

If it turns out you don’t have that default.target you can make it like explained here.


which lead me to looking for an existing target with the same properties.

This all said this is work around not a solution. Those who made this service/install need to be aware of this issue and fix whatever is amiss in the service file.

2 Likes

Restart what?

it means to restart systemd itself (reload hasio-supervisor in its new order). If you don’t do that before reboot the next shutdown (i.e. reboot) will still hang (although next after that should be fine)

Systemd way to reboot is sudo systemctl reboot. BTW Nice to make an alias for that to override whatever might be in /sbin/reboot