[Solved} Supervisor is running in an unhealthy state (because of watchtower container!)

Installation
1

Hello.

My Supervisor is running in an unhealthy state.
Latest version is 2020.12.7, but installed is 2021.01.dev0801.
I think this was my watchtower container which updated the supervisor.
I disabled it, deleted the supervisor container and hassio recreated it immediately, but again the newest dev version…

How can I get the right supported one installed again?

2

I run today in same problem with watchtower.

Unhealthy Home Assistant because of watchtower.
If the Supervisor logs (Frontend > Supervisor > System) reports that you have containers that are not supported, you need to remove the images from the host.

In my case I was running containrrr/watchtower .
To remove it, on the host execute:

docker rmi containrrr/watchtower:latest

If you’re running Portainer this can be done under Images .
Then restart Supervisor (Frontend > Supervisor > Restart). After a minute, if you reload the page, the unhealthy state should be gone

Big thanks to :

1 Like
3

Great!! Removing the watchtower image was the solution!
I even didn’t notice that there was an entry of unsupported watchtower container in the log…

Big thanks!

4

I shoulb be free of using what i want i dont use wathtower for HA but i have other containers!

1 Like
5

I find the current enforced restrictions of a unhealthy system so incredibly irritating. I understand that there are requirements for a system to be considered healthy. But why forcefully forbid us of updating HA? Not even giving us the freedom to choose to ignore the warnings and accept the risks?
I have watchtower configured to only update containers with a specific label, so it can’t even touch my HA related containers. The easy workaround is to remove watchtower every time I want to install an update and then enable it again. It’s not that much effort, but still annoying.

4 Likes
6

I feel your pain they don´t care abou us!

2 Likes
7

same issue here, they should look for a workaround, watchtower can be an issue if you dont have a configuration restriction and allows it to update all the images, but if its controlled(using labels) its not a problem for hass.

1 Like
8

And now Portainer itself is on the banned list, so a heck of a lot of Docker installs will be stuck on the current version!

3 Likes
9

please reverse this change. Add portainer as container orchestra by pvizeli · Pull Request #3889 · home-assistant/supervisor · GitHub - I see the reason to block Watchtower, even I didn’t liked it but now Portainer. I will not run a dedicated machine only for hassio, that’s just ridiculous.

10 Likes
10

Then you should switch to a container install. Or run HA in a VM and add other VMs for other software. The only supported way to run Supervisor is on a dedicated machine.

11

For what it’s worth I could upgrade to latest supervisor and core with portainer installed. Adding portainer to the list seems like a poor choice.

Downgrading to container install is not really a friendly suggestion…

I would suggest removing portainer to update… And then do what you want.

What does portainer do that docker cli doesn’t? That’s rhetorical, I’m sure there is stuff I can do with portainer to break things…

12

Mostly makes it far easier to get into bad situations. It’s gui based so it makes it very easy to change all sorts of settings that would break. You can absolutely do the same things with the cli but you have to know what you’re doing much more. It doesn’t exactly guide you to all the options that break supervisor.

But I mean realistically using the docker cli isn’t really supported either. At least not to make changes, obviously something like checking logs is fine. There’s no check for that because it’s impossible. But really Supervisor is only supported as an appliance install. It doesn’t matter whether you use HAOS or supervised. If you run supervised the expectation is that you ran the installer and then didn’t access the host shell again other then to rerun the installer. If you run HAOS then the expectation is that you never access the host shell. Basically the same thing.

If you want a normal Linux system that you manage with all the usual tools that also runs home assistant then you should use the container install. That’s what it’s there for.

13

I mean I get that and it makes sense.

I’d actually quite happily run HAOS, I quite like it. It’s much easier to deal with when you have no Linux background.

The only reason I learnt to run supervised was so I could make my addon to be fair.

The main reason I run portainer not as an addon directly is it makes it easier to troubleshoot, particularly restores. As it loads before homeassistant.

Sure I could run container, it would have made my addon not needed. I wouldn’t have learnt how to make an addon(poorly) and would have to find containers to replace my existing addons… I would probably be better in Linux now though(maybe) or perhaps better in yaml.

I could quite happily break stuff nearly as well with docker cli now though.

The better way to do that commit linked a few posts up would have been to make it positive…

Healthy containers 
Null

Perhaps I should look into running a vm on my rpi to install HAOS…

1 Like
14

Not that I’m encouraging running portainer but for the record, running before homeassistant is an option for addons. See startup in here:

initialize will start add-on on setup of Home Assistant. system is for things like databases and not dependent on other things. services will start before Home Assistant, while application is started afterwards. Finally once is for applications that don’t run as a daemon.

Truth be told, if there’s a piece of software out there that you like and they publish a docker image it’s usually not too difficult to turn it into an addon. You don’t even need a git repo if you just want to make it for yourself, just use /addons.

Some require more effort then others. I feel like the main thing when I do it is usually just finding what folders it uses and using ln to actually make the software store things in /data that should be persistent and look for things in /share or /ssl that it needs as input (for ones that want config files instead of envs and args). But then it can be managed entirely through HA so there’s benefit. And this is only for the ones where someone didn’t do the work for you, people have made and shared a lot of addons on here.

15

If I was going to do that it would be with the portainer addon that is available…
It would probably achieve starting prior to anything else during a restore, although it also hides the HA related containers.

So I could fiddle with that.

I could even run it as local addon.
Or I could just run portainer directly as a container.

Perhaps it’s time to remove the Supervised install guide… Just list 3 install methods.

1 Like
16

Hi Y’All,

I installed the Supervised version many years ago and I’ve totally forgetten why! ROFL. Wasn’t there a restriction on accessing add-ons or cloud-access in the past that made it more ‘functional’ than a straight container-based deployment?

Regards,
Keith

17

I’m posting on an alt for… reasons. English is also not my first. This change is completely absurd. Having portainer itself as a blacklisted unhealthy trigger??! I run a home automation youtube channel and have always supported and advocated for yall in the past. As you guys slowly tightened down the ‘security’ of home assistant, I made small adjustments and went along. It helps people with no experience prevent something bad happening. I understood, to an extent.

But there comes a point where you are clearly overstepping bounds. Running portainer separate from home assistant has its benefits. Due to the limited CPU/GPU speed, bugs in some of the addons and integrations, sometimes the system gets bogged up. The less powerful the machine, the quicker this happens.

To the point where the system is not reachable. 90/100 pings fail. It’s a headless unit I am running it on, completely inaccessible and behind a literal wall.

The only solution when something goes haywire like that (usually deepstack or something memory intensive), is rebooting and QUICKLY logging into portainer to shutdown the home assistant container itself. I am then able to SSH in, cleanup what is needed, and restart everything.

Having portainer running as an ‘addon’ (even BEFORE home assistant starts) is just not sufficient.

Please revert this change. My followers and many others will be forced to stay on previous versions or slowly lose interest/motivation due to the unncessary work. Other projects will come along and make home assistant redundant long-term if cutting people out like this keeps up. Especially with the rise of start-ups as well as Google taking initiative this year in the automation scene. (Matter catalyst)

8 Likes
18

The No1 priority of any software project/developer is reliability/stability. As @CentralCommand explained so many times in the past running HAOS or Supervised (HASU) is a closed loop system, allowing tinkering within the bounds of the system. HASU, if left unchecked, generates so much unnecessary noise in the forums, which distracts from the prime objective of HA, which is to reliably run an automation/control system.

If you like tinkering outside the bounds of the HAOS/HASU system then Container (HACO) is your other option, which is boundless, but requires a skilled operator to navigate the environment.

For anyone without the skill or the time to tinker, HAOS/HASU is available to them. For everyone else, HACO is the way to go offering boundless tinkering.

For anyone interested primarily in the automation/control side of things, I strongly suggest HAOS as it is the environment with the least demands in terms of system administration and the most reliable in terms of operation. It also provides a predictable environment to facilitate speedy assistance when, infrequently, issues arise.

19

If HASU is causing so much havoc in the forums, then obviously the solution is to cull that install option if it detracting from the main purpose of the forums. Removing portainer isn’t going to lessen the havoc.

3 Likes
20

Just a simple GUI option that requires confirmation you’re happy you may trash your system by using Portainer would be a more ‘open’ solution to an open source project. I appreciate Mike’s very clear and detailed explanations here and I get the merit of trying to keep things safe, but just like a lot of things (click 6 times to get Android developer options), we should have an option to be trusted and keep things flexible.

3 Likes