fix(omni-tools): let the add-on stop by backgrounding nginx and running the entrypoint as PID 1 (#3050)

The add-on could not be stopped: Home Assistant showed an Error status
after a few seconds and the container kept running and still served the
web UI (#3049).

cont-init.d/99-run.sh started nginx in the foreground -- '&>' is a
redirect, not a background operator -- and ha_entrypoint.sh runs every
cont-init.d script sequentially in the foreground. That script therefore
never returned, so the entrypoint never reached the code that installs
the terminate() handler forwarding SIGTERM to the application. The
reporter's log shows both halves of this: it prints 'Starting custom
scripts' and never reaches 'Everything started!'.

The add-on also shipped no 'init:' key, so Supervisor's default of true
made Docker inject its own init as PID 1 and left ha_entrypoint.sh as
PID 2, where the 'if $PID1' block holding the trap is skipped outright.

Background the launch and set init: false. The script then returns, the
entrypoint installs its trap, and nginx -- orphaned by the exiting
script -- is reparented to the entrypoint as PID 1, where terminate()'s
'pgrep -P $$' finds it and signals it directly.

Backgrounding from cont-init.d is what 24 other add-ons here already do
(autobrr runs a bare 'nginx &'). Moving the launch to services.d was
considered and rejected: ha_entrypoint.sh runs each services.d/*/run
inside a restart subshell, so the application ends up a grandchild of
PID 1 while terminate() enumerates direct children only. Reproduced --
the app survives that path unsignalled -- and it is the larger change.

Co-authored-by: Claude Opus 5 <noreply@anthropic.com>

omni-tools/CHANGELOG.md

@@ -1,3 +1,6 @@
+## 0.6.1.1 (2026-09-07)
+- Fix the add-on refusing to stop: Home Assistant reported an Error status after a few seconds and the container kept running and serving the web UI. `cont-init.d/99-run.sh` started nginx in the foreground, and `ha_entrypoint.sh` runs every cont-init script in the foreground, so the entrypoint never reached the point where it installs the `terminate()` handler that forwards SIGTERM to the application on shutdown. The application is now started in the background, and `init: false` makes the entrypoint run as PID 1 so the orphaned process is reparented to it and receives that signal. Closes #3049.
+
 
 ## 0.6.1 (2025-11-18)
 - Added `env_vars` option to allow passing custom environment variables from the add-on configuration.

omni-tools/config.yaml

@@ -5,6 +5,7 @@ description:
   Self-hosted collection of powerful web-based tools for everyday tasks.
   No ads, no tracking, just fast, accessible utilities right from your browser
 image: ghcr.io/alexbelgium/omni-tools-{arch}
+init: false
 map:
   - addon_config:rw
 name: Omni Tools
@@ -20,5 +21,5 @@ schema:
       value: str?
 slug: omni-tools
 url: https://github.com/alexbelgium/hassio-addons
-version: 0.6.1
+version: 0.6.1.1
 webui: "[PROTO:ssl]://[HOST]:[PORT:80]"

omni-tools/rootfs/etc/cont-init.d/99-run.sh

@@ -7,4 +7,10 @@
 
 # Start omni-tools container content
 bashio::log.info "Starting application"
-/./docker-entrypoint.sh nginx -g "daemon off;" &> /proc/1/fd/1
+# Backgrounded on purpose. ha_entrypoint.sh runs every cont-init.d script in the
+# foreground, so launching nginx here in the foreground never lets it reach the
+# terminate() handler that forwards SIGTERM on shutdown -- the add-on then could
+# not be stopped at all (#3049). Backgrounded, this script returns, nginx is
+# reparented to the entrypoint as PID 1, and terminate() signals it directly.
+# Requires init: false in config.yaml, which is what makes the entrypoint PID 1.
+/./docker-entrypoint.sh nginx -g "daemon off;" &> /proc/1/fd/1 &