Package: org.wordpress.unmanaged.cloudronapp (observed on 3.15.0; logic also present in the managed package's SSO block)
File: /app/pkg/start.sh — OIDC/Cloudron-SSO setup block (~lines 182–204)
Severity: High — puts the app into a boot crash-loop / recovery (debug) mode; site goes fully offline.
Reproduced on: live app c21masters.com (Cloudron 6.0.0), 2026-06-19.

Symptom

App drops into recovery mode. cloudron logs shows start.sh restarting in a tight loop, each pass ending with:

Success: Installed 1 of 1 plugins.
Warning: Failed to activate plugin. Cloudron SSO requires 1 plugin to be installed and activated: OpenID Connect Generic.
Error: No plugins activated.

…and the web tier never comes up:

=> Healthcheck error: Error: connect ECONNREFUSED 172.18.20.70:80

Apache is never reached because start.sh exits non-zero before the Starting apache step.

Root cause

start.sh begins with set -eu, so any unhandled non-zero exit aborts the whole startup script. The SSO block:

# uninstall old `openid-connect-generic` plugin
if $wp plugin is-installed openid-connect-generic; then
    $wp plugin deactivate openid-connect-generic || true
    $wp plugin uninstall openid-connect-generic || true
fi

if ! $wp plugin is-installed daggerhart-openid-connect-generic; then
    echo "==> Install OIDC plugin"
    $wp plugin install /app/pkg/daggerhart-openid-connect-generic.zip
    $wp plugin activate daggerhart-openid-connect-generic     # (A) only runs on fresh install
fi

$wp plugin install --force /app/pkg/cloudron-sso.zip
$wp plugin activate cloudron-sso                              # (B) hard requirement

cloudron-sso.php declares a WordPress 6.5+ plugin-dependency header:

Requires Plugins:  daggerhart-openid-connect-generic

WordPress refuses to activate cloudron-sso unless daggerhart-openid-connect-generic is installed and active.

The activation of the dependency (A) lives inside the if ! is-installed guard. So if daggerhart-openid-connect-generic is already installed but inactive — which happens whenever the plugin was deactivated by a user, by a migration/restore, by a backup import, or by a previous half-completed boot — the guard is false, (A) is skipped, and the dependency stays inactive.

(B) then fails the Requires Plugins check → non-zero exit → set -eu aborts start.sh before Apache starts → healthcheck ECONNREFUSED → Cloudron restarts the container → same path again → recovery mode.

The "different name" red herring: the historical directory/slug openid-connect-generic was renamed to daggerhart-openid-connect-generic. Installs that carry the plugin from before the rename (or restore it inactive) land exactly in this installed-but-inactive state.

Why it's easy to hit

• The dependency is only activated on the fresh-install path, but it's required-active on every boot.
• Any state where the OIDC plugin exists on disk but isn't active is unrecoverable on its own, because each reboot re-runs the same failing sequence.

Fix

Move/guarantee activation of the dependency on every boot (idempotent), independent of whether it was just installed, and/or make the SSO activation non-fatal. Minimal change:

if ! $wp plugin is-installed daggerhart-openid-connect-generic; then
    echo "==> Install OIDC plugin"
    $wp plugin install /app/pkg/daggerhart-openid-connect-generic.zip
fi
# Always ensure the dependency is active before activating cloudron-sso (idempotent).
$wp plugin activate daggerhart-openid-connect-generic

$wp plugin install --force /app/pkg/cloudron-sso.zip
$wp plugin activate cloudron-sso

Optional hardening: append || true (or an explicit warn) to the two SSO activate calls so a future SSO hiccup degrades gracefully instead of taking the entire site offline via set -eu. SSO not activating should not block Apache from serving.

Workaround (manual recovery, what we did)

From inside the container (cloudron exec --app <id>

cd /app/data/public
php -d memory_limit=512M /app/pkg/wp plugin activate daggerhart-openid-connect-generic --allow-root --skip-themes
php -d memory_limit=512M /app/pkg/wp plugin activate cloudron-sso --allow-root --skip-themes

Then take the app out of recovery mode:

cloudron debug --disable --app <id>

After this the next normal boot reaches ==> Starting apache, healthcheck passes, app returns to running, site responds HTTP 200.

Environment

• Cloudron: 6.0.0
• Package: org.wordpress.unmanaged.cloudronapp@3.15.0
• cloudron-sso 1.0.0, daggerhart-openid-connect-generic (OpenID Connect Generic) 3.11.3
• App ID: 4b378989-212e-4ca0-921c-2479fa2a0679