Auto-reconnect and reload after a successful restart (v0.16.24)

README.md

@@ -12,7 +12,7 @@
     <img alt="Docker" src="https://img.shields.io/badge/Docker-ready-2496ED?logo=docker&logoColor=white">
     <img alt="Architectures" src="https://img.shields.io/badge/platform-amd64%20%7C%20arm64-5965F2">
     <img alt="Caddy" src="https://img.shields.io/badge/powered%20by-Caddy-1F88C0">
-    <img alt="Version" src="https://img.shields.io/badge/version-0.16.21-62E6A7">
+    <img alt="Version" src="https://img.shields.io/badge/version-0.16.24-62E6A7">
   </p>
   <p>
     <a href="#why-site-gateway">Why Site Gateway</a> ·

ROADMAP.md

@@ -168,3 +168,9 @@ Roughly in priority order:
 `v0.16.20` audits role enforcement across the app after a run of Administration changes and fixes three places where the frontend showed a control the backend would actually reject for Standard Users and Viewers: the Dashboard's "Resync now" button (Needs Attention drift tile) and the Certificates page's "Run certificate check" button are now hidden for anyone who isn't an administrator, since both call administrator-only endpoints. The Access List editor's "Allowed groups" section -- previously always rendered with an empty `state.groups`, so a Standard User just saw a false "No groups have been created yet." -- now shows an accurate note pointing to an administrator instead, both when creating a new Access List and editing an existing one. Also corrected the in-app documentation: the Users & Groups role summary previously said Viewer "can inspect everything," which wasn't true -- Administration (System, Users, Groups, Backups, API Access, Logs & Retention, Danger Zone) is completely invisible to Viewer, the same as Standard, not merely read-only. The role summary, the Access Lists doc's Groups field, the Certificates doc's Check now section, and the Dashboard doc's Resync now section all now say plainly which actions are administrator-only.
 
 `v0.16.21` gives API Access tokens full parity with every other tile type. Tokens now get a real, persistent custom icon -- a new `icon`/`icon_slug` column pair on the `api_tokens` table (added via an idempotent `ALTER TABLE`, safe on existing installs), matching storage functions, and a `tokens` branch in the shared icon-upload/search/URL routes -- plus the same "•••" card menu every other tile has, with Change icon and Revoke token moved into it. While wiring this up, found and fixed a real pre-existing bug: Groups' own "Change icon" menu item has been broken since it shipped, because the frontend code that actually saves an icon never mapped the `groups` kind to anything and silently fell through to the Hosted Sites endpoint, which always 404'd. Also finished the rest of the API Access fix list: the Full access/Read-only counts in the summary bar now only tally active tokens, so they stay consistent with the Active/Revoked split instead of quietly including tokens that can no longer authenticate; a "Hide revoked" toggle sits at the right of that same summary bar for anyone who's revoked enough tokens over time that the tile grid gets cluttered; and the documentation now explains why a revoked token can't be deleted outright -- the record stays for the same accountability reasons the Audit log is never editable.
+
+`v0.16.22` fixes Docker socket detection for the common case where `/var/run/docker.sock` is correctly bind-mounted but Site Gateway still reports "not detected." Root cause: `detectDockerSocket()` checks that the running process can actually read the socket, but the container drops straight from root to the unprivileged `PUID:PGID` with no supplementary groups, and the socket is typically owned `root:docker` on the host with mode 660 -- so a perfectly correct mount still fails an unprivileged read check with no group membership behind it. `docker-entrypoint.sh` now handles this automatically: while still root, it reads the socket's actual group GID directly off the mount (no hardcoded GID -- it varies by host, Unraid, Debian, Synology, and others all differ), creates a matching local group if one doesn't already exist, adds the app user to it, and hands `su-exec` a username instead of a bare `uid:gid` so supplementary groups actually apply via `initgroups()`. Every step is best-effort and guarded: if anything about the detection or group setup fails, the container starts exactly as it always has, just without Docker integration, the same as if the socket weren't mounted at all. Also documented in the System tab's Environment & Integrations section, including the one thing this can't route around: the check runs once at boot, so a container that already has the mount added still needs an actual restart, not just a reload, to pick it up.
+
+`v0.16.23` fixes the "Restart application" button on the System tab doing nothing at all after you confirm the restart in its popup: the dialog closes, the button text never changes to "Restarting...", no toast appears, and no restart actually happens -- explaining why the earlier restart-not-logged report showed no trace anywhere (no activity entry, no audit entry, no fresh boot sequence in the container's own console log), because the request never reached the server in the first place. Root cause: `event.currentTarget` is only valid while a DOM event is still being dispatched -- the browser resets it to `null` once dispatch finishes. The Restart handler read `event.currentTarget` *after* `await`-ing the confirmation dialog, by which point the click event had long since finished dispatching, so that line threw against a null reference before ever reaching the `/api/system/restart` call, and the error had nowhere to surface since it happened outside the handler's own try/catch. Resync and Reload were never affected because both of those capture their button reference as their very first line, before any `await`. Fixed by capturing the button reference synchronously at the top of the Restart handler too, matching the other two.
+
+`v0.16.24` fixes the "Restart application" button never recovering after a successful restart -- following v0.16.23's fix for the button doing nothing at all, a real restart now goes through correctly (the audit log and activity feed both record it as expected), but the button itself was left stuck on "Restarting..." forever, since nothing in the success path ever reset it or reloaded the page. The handler assumed the toast alone was enough and stopped there, unlike the Danger Zone's Factory Reset flow, which already polls for the server coming back online and reloads automatically. Restart now does the same: once the restart request is accepted, it polls `/api/session` once a second for up to 30 seconds and reloads the page as soon as the dashboard answers again (with a status line explaining what it's waiting on), falling back to a reload regardless if that window elapses -- so the button, and the rest of the UI, recover on their own instead of requiring a manual page refresh.

docker-entrypoint.sh

@@ -29,9 +29,51 @@ fi
 export XDG_DATA_HOME="${DATA_DIR:-/data}/certificates/managed"
 export XDG_CONFIG_HOME="${DATA_DIR:-/data}/caddy/config"
 
+# --- Docker socket group access -------------------------------------------------------------
+# A bind-mounted /var/run/docker.sock is typically owned root:docker on the host with mode
+# 0660 -- readable only by root or members of that group. The app drops straight to an
+# unprivileged PUID:PGID with no supplementary groups, so even a correctly mounted socket looks
+# "not detected" to it. The Docker group's GID varies host to host (Unraid, Debian, Synology,
+# etc. all differ), so rather than hardcode one, read it directly off the mounted socket while
+# still root, make sure a local group with that GID exists and the app user is a member of it,
+# then hand su-exec a username instead of a bare uid:gid so it picks up supplementary groups via
+# initgroups() -- the uid:gid form only ever sets the one primary group. Every step here is
+# best-effort: if anything fails, app_exec_target stays the original "$app_uid:$app_gid" and the
+# app starts exactly as it always has, just without Docker integration -- same as an unmounted
+# socket, never worse.
+app_exec_target="$app_uid:$app_gid"
+docker_socket="/var/run/docker.sock"
+if [ -S "$docker_socket" ]; then
+  docker_gid="$(stat -c '%g' "$docker_socket" 2>/dev/null || true)"
+  if [ -n "$docker_gid" ] && [ "$docker_gid" != "$app_gid" ]; then
+    docker_group_name="$(getent group "$docker_gid" 2>/dev/null | cut -d: -f1 || true)"
+    if [ -z "$docker_group_name" ]; then
+      addgroup -g "$docker_gid" sgdockersock 2>/dev/null || true
+      docker_group_name="$(getent group "$docker_gid" 2>/dev/null | cut -d: -f1 || true)"
+    fi
+    if [ -n "$docker_group_name" ]; then
+      app_group_name="$(getent group "$app_gid" 2>/dev/null | cut -d: -f1 || true)"
+      if [ -z "$app_group_name" ]; then
+        addgroup -g "$app_gid" sgapp 2>/dev/null || true
+        app_group_name="$(getent group "$app_gid" 2>/dev/null | cut -d: -f1 || true)"
+      fi
+      if [ -n "$app_group_name" ] && ! getent passwd "$app_uid" >/dev/null 2>&1; then
+        adduser -D -H -u "$app_uid" -G "$app_group_name" sgapp 2>/dev/null || true
+      fi
+      app_user_name="$(getent passwd "$app_uid" 2>/dev/null | cut -d: -f1 || true)"
+      if [ -n "$app_user_name" ]; then
+        addgroup "$app_user_name" "$docker_group_name" 2>/dev/null || true
+        if id -nG "$app_user_name" 2>/dev/null | grep -qw "$docker_group_name"; then
+          app_exec_target="$app_user_name"
+        fi
+      fi
+    fi
+  fi
+fi
+
 su-exec "$app_uid:$app_gid" caddy run --config "$caddyfile" --adapter caddyfile &
 caddy_pid=$!
-su-exec "$app_uid:$app_gid" "$@" &
+su-exec "$app_exec_target" "$@" &
 app_pid=$!
 
 shutdown() {

package.json

@@ -1,6 +1,6 @@
 {
   "name": "site-gateway",
-  "version": "0.16.21",
+  "version": "0.16.24",
   "private": true,
   "description": "Site Gateway: simple self-hosted website publishing, reverse proxying, and automatic HTTPS.",
   "type": "module",

src/public/features.js

@@ -604,9 +604,24 @@ function renderSystemPanel() {
       finally { button.disabled = false; button.textContent = original; }
     });
     panel.querySelector("#system-restart").addEventListener("click", async event => {
+      const button = event.currentTarget;
       if (!await themedConfirm("Restart Site Gateway?", "The application will stop and restart. This takes a few seconds and briefly interrupts hosted sites and the dashboard.", "Restart")) return;
-      const button = event.currentTarget; button.disabled = true; button.textContent = "Restarting\u2026";
-      try { await api("/api/system/restart", { method: "POST" }); toast("Restarting \u2014 this dashboard will be unavailable briefly."); }
+      button.disabled = true; button.textContent = "Restarting\u2026";
+      const restartStatus = document.querySelector("#system-restart-status");
+      try {
+        await api("/api/system/restart", { method: "POST" });
+        toast("Restarting \u2014 this dashboard will be unavailable briefly.");
+        button.textContent = "Waiting for Site Gateway\u2026";
+        if (restartStatus) restartStatus.textContent = "Reconnecting once Site Gateway comes back online\u2026";
+        for (let attempt = 0; attempt < 30; attempt++) {
+          await new Promise(resolve => setTimeout(resolve, 1000));
+          try {
+            const response = await fetch("/api/session", { cache: "no-store" });
+            if (response.ok) { location.reload(); return; }
+          } catch { /* Still restarting -- the dashboard is briefly unreachable while the container comes back up. */ }
+        }
+        location.reload();
+      }
       catch (error) { toast(error.message, "error"); button.disabled = false; button.textContent = "Restart application"; }
     });
   }