WissKI Drupal package update failures¶
Symptom¶
Updating Drupal/WissKI packages from SCS Manager (component → Installed Drupal packages → apply environment) fails early with watchdog errors such as:
Failed to secure Drupal database: Failed to dump databasecURL error 28: Operation timed out after 30000 millisecondson a Portainer URL ending in/docker/exec/.../start
Cause¶
The pre-update safety step runs mariadb-dump inside the WissKI Drupal container via the Portainer Docker exec API.
Two common failure modes:
- HTTP timeout (cURL error 28) — the exec
/startrequest used Guzzle's default 30 s timeout whilemariadb-dumpwas still running. - Wrong database host — the dump command used
-hdatabase, but WissKI instances connect to the shared MariaDB container atscs--database(seeDB_HOSTin the wisski-base-stack env). The hostnamedatabasedoes not resolve insidewisski-*--drupal, so the dump exits non-zero with no stderr when run detached.
Fix (module)¶
soda_scs_manager now:
- Uses a 600 s default HTTP timeout for Docker exec/run API calls (matching other Portainer requests).
- Runs database dumps in detached exec mode and polls until completion (up to 30 minutes).
- Reads the database host from
dbHostin SCS Manager settings (scs--databaseon this deployment) instead of hardcodingdatabase.
Deploy the updated soda_scs_manager module to scs-manager--drupal and retry the package update.
After redeploy, SCS Manager polls /health on the raw WissKI URL for up to 10 minutes while status is starting (HTTP 404 from Traefik before Drupal is wired) or unavailable (502/503). A single immediate 404 right after redeploy is normal; the update should not fail until that window expires.
If it still fails¶
- Check watchdog (
drush watchdog:show --type=soda_scs_manager) for the exact exec URL and exit code. - Confirm Portainer can reach the WissKI stack endpoint (
deployments.scs.<domain>). - Test a manual dump inside the WissKI Drupal container; if that is slow or fails, fix database connectivity or disk space first.