Latest base image with s6-overlay v3 breaks add-on

I develop an add-on for Prometheus Node Exporter. I’m not a Home Assistant expert, but I was able to throw this add-on together.

A user notified me that the latest s6-overlay v3 change was breaking new installs of the add-on. I tried the changes as suggest in the developer blog post, and looked through the commit history in the example, but still can’t get the add-on to start.

s6-overlay-suexec: fatal: can only run as pid 1

Can someone with some add-on development experience look at my repo and tell me what I’m missing? I also set "init": false in my config.json, but without any luck.

3 Likes

I’m no expert either, but I’m seeing the same thing. I made some changes to my custom local addon and since it failed to build in my HA install on RPi 3b+, I set up the VS Code devcontainer as instructed here: https://developers.home-assistant.io/docs/add-ons/testing

This helped me figure out why the build was failing and fix it, but when I tried to start the addon, it failed with “s6-overlay-suexec: fatal: can only run as pid 1”. Adding "init": false to my config.json didn’t help.

@anyberry
My issue is apparently a bug, so it might not apply to your specific case. Do you have a public repo I can look at?

Do you also need to turn off protection mode in your addon by any chance? That is what the bug is about, it appears those two options don’t work together like they should.

Otherwise setting init to false has always made that error go away in my testing. I would definitely take a look if you have a link.

It started working for me. It was probably the "init": false, but for some reason it didn’t take effect at first. The thing is that I saw that error when I started the addon in a devcontainer in VS Code. I was able to fix it with that option. But when I tried it in my real HA installation, it still wouldn’t start and that instance doesn’t have much logging enabled, so I didn’t see any error. But then I updated HA OS which caused a reboot of the whole thing and afterwards it started working - magic I guess.

BTW, my addon is here (the README is a bit outdated - I’m no longer using gunicorn+Flask): GitHub - mmalina/zabiny-temp: Local temperature in Brno-Žabovřesky

So when you have a local addon installed from /addons the “rebuild” button only rebuilds the image from the existing config. If you updated the config.json (or config.yaml) then “rebuild” does not look at that, it rebuilds it from the known config.

Restarting the host does though since it forces supervisor to re-read the config file for the addon back into its cache. You can also force this re-read without a restart by either:

  1. Uninstalling or re-installing the addon
  2. Updating the version in config.json and then updating the addon to the new version.

The /addons folder was mostly meant for development testing so it has some confusing quirks like this. But I would bet this is what happened to you. For me personally I use #2 above when doing development of a local addon as its basically the same as the rebuild button.

Thanks for the additional details. Yeah, I tend to increase the version as well. But I guess I didn’t do it this time.