Two related additions covering the 2026-05-31 cutover-night incidents on majorlinux and majortoot-hetzner. ssh-socket-tailscale-race-condition.md (update Race 1 fix): - After=tailscaled.service Requires=tailscaled.service orders against the service becoming active, not against tailscale0 having an IPv4 — hosts kept losing SSH intermittently after reboots (incident: majorlinux + majortoot-hetzner 2026-05-31, during cutover-night Ansible reboot). - Canonical fix: a oneshot tailscale-wait-ready.service that polls `ip -4 -o addr show tailscale0` until an address is present, with ssh.socket After=/Requires= that service. Document the full evolution (2026-05-19 BindsTo → 2026-05-23 Requires → 2026-05-31 wait-ready) so future readers don't try the half-fixes thinking they're sufficient. - Add majortoot-hetzner to affected hosts. mastodon-post-install-hardening.md (new): Four upstream-install gaps that bit during the majortoot-hetzner cutover: 1. /home/mastodon at 0750 (useradd default) → nginx www-data can't traverse → every static asset 403s → unstyled "purple screen" in the browser while API/HTML still work through the puma proxy. 2. .env.production at 0644 (mastodon-setup default) → DB_PASS, SECRET_KEY_BASE, OTP_SECRET world-readable once gap (1) is fixed. 3. mastodon user shell at /usr/sbin/nologin → `su - mastodon` blocked. 4. rbenv init in .bashrc only → login shells don't source .bashrc; even when chained, Ubuntu's .bashrc returns early for non-interactive shells. Fix: .bash_profile sets up rbenv BEFORE sourcing .profile + .bashrc, so it works for both interactive and non-interactive logins. All four codified in MajorAnsible configure_mastodon_permissions.yml with self-asserting verification steps. 02-selfhosting/index.md + SUMMARY.md: Add a "Services" section to the selfhosting index linking the mastodon-post-install-hardening article (and the other orphaned services/ entries while there). SUMMARY.md gains one new entry. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
148 lines
6.5 KiB
Markdown
148 lines
6.5 KiB
Markdown
# Tailscale Boot Race Conditions (SSH Unreachable After Reboot)
|
|
|
|
Two related race conditions can make a host unreachable via Tailscale after reboot. Both stem from systemd services starting before Tailscale or the network is ready.
|
|
|
|
---
|
|
|
|
## Race 1: ssh.socket Binds Before Tailscale Is Up (Ubuntu)
|
|
|
|
### Symptom
|
|
|
|
SSH to a host via Tailscale IP times out. `tailscale ping` works, `tailscale status` shows `active; direct`, but SSH on port 22 refuses connections. No access via Hetzner console if root password is unset.
|
|
|
|
### Cause
|
|
|
|
Ubuntu 24.04 uses systemd **socket activation** for SSH (`ssh.socket` instead of persistent `ssh.service`). When the socket override binds to a Tailscale IP, it can start *before* `tailscaled.service` is ready. The bind may succeed initially (Tailscale state file caches the IP), but a later Tailscale reconnect or interface reset invalidates the bound address silently — SSH dies with no recovery path.
|
|
|
|
### Diagnosis
|
|
|
|
```bash
|
|
# From another host:
|
|
tailscale ping <IP> # succeeds — host is up
|
|
ssh root@<IP> # times out — sshd not listening
|
|
|
|
# After gaining console access or reboot:
|
|
systemctl status ssh.socket # check Listen: address
|
|
journalctl -b -1 -u ssh # likely empty — sshd never spawned
|
|
journalctl -b -1 -u ssh.socket # socket started before tailscaled
|
|
```
|
|
|
|
### Fix (current — 2026-05-31)
|
|
|
|
`After=tailscaled.service` orders against the service becoming `active` — **not** against the `tailscale0` interface actually having an IPv4 address. tailscaled flips to active within a second of starting, but the kernel doesn't have the address bound to the interface until DERP relays connect and the control plane confirms the node. ssh.socket attempting `ListenStream=<TS IP>:22` in that window fails with `Cannot assign requested address`, the socket goes into a failed state, and there is no automatic retry.
|
|
|
|
The proper gate is a dedicated readiness service that **waits for the tailscale0 IPv4 address to exist** before letting ssh.socket bind:
|
|
|
|
```ini
|
|
# /etc/systemd/system/tailscale-wait-ready.service
|
|
[Unit]
|
|
Description=Wait until tailscale0 has an IPv4 address
|
|
After=tailscaled.service
|
|
Requires=tailscaled.service
|
|
ConditionPathExists=/usr/sbin/ip
|
|
|
|
[Service]
|
|
Type=oneshot
|
|
RemainAfterExit=yes
|
|
TimeoutStartSec=120
|
|
ExecStart=/usr/bin/bash -c 'for i in $(seq 1 120); do ip -4 -o addr show tailscale0 2>/dev/null | grep -q "inet " && exit 0; sleep 1; done; exit 1'
|
|
|
|
[Install]
|
|
WantedBy=multi-user.target
|
|
```
|
|
|
|
```ini
|
|
# /etc/systemd/system/ssh.socket.d/override.conf
|
|
[Unit]
|
|
After=tailscale-wait-ready.service
|
|
Requires=tailscale-wait-ready.service
|
|
|
|
[Socket]
|
|
ListenStream=
|
|
ListenStream=<TAILSCALE_IP>:22
|
|
```
|
|
|
|
Reload + restart:
|
|
|
|
```bash
|
|
systemctl daemon-reload
|
|
systemctl enable tailscale-wait-ready.service
|
|
systemctl restart ssh.socket
|
|
ss -tlnp | grep :22 # verify bound to Tailscale IP
|
|
```
|
|
|
|
!!! note "Evolution of this fix"
|
|
- **2026-05-19 v1** — `After=tailscaled.service` + `BindsTo=tailscaled.service`. Worked initially but caused a shutdown-time ordering cycle.
|
|
- **2026-05-23 v2** — `BindsTo` swapped for `Requires` to break the cycle. Fixed the cycle but did **not** wait for `tailscale0` to actually have an IP — just for `tailscaled` to be active. Hosts continued losing SSH after some reboots (intermittent, depending on whether the race won).
|
|
- **2026-05-31 v3** — Added `tailscale-wait-ready.service` to gate ssh.socket on the interface having an address. This is the current canonical fix.
|
|
|
|
!!! warning "Do NOT use BindsTo"
|
|
`BindsTo=tailscaled.service` creates a **systemd ordering cycle** during shutdown: `basic.target → sockets.target → ssh.socket → tailscaled.service → basic.target`. Systemd breaks the cycle by deleting jobs unpredictably, which can prevent `ssh.socket` from starting on the next boot. Use `Requires=` for startup ordering without the bidirectional lifecycle coupling.
|
|
|
|
### Affected Hosts
|
|
|
|
Ubuntu hosts using `configure_tailscale_ssh_only.yml`: majorlinux, dcaprod-hetzner, tttpod-hetzner, majortoot-hetzner. Fedora hosts (majordiscord) use firewall rules for SSH restriction — not affected by this race.
|
|
|
|
---
|
|
|
|
## Race 2: tailscaled Starts Before Network Is Online (All Hosts)
|
|
|
|
### Symptom
|
|
|
|
Host reboots but never appears on Tailscale. `tailscale ping` times out entirely. SSH is dead because Tailscale never connects. The host is up (accessible via provider console) but isolated from the Tailscale network.
|
|
|
|
### Cause
|
|
|
|
`tailscaled.service` ships with `After=network-pre.target`, which fires *before* the network interface has an IP. On VPS hosts (especially Hetzner), the interface can take several seconds to come online. Tailscale starts, sees no network (`SetNetworkUp(false)`, `link state: defaultRoute= ifs={} v4=false v6=false`), fails DNS bootstrap and DERP relay connections, and gets stuck — never retrying.
|
|
|
|
### Diagnosis
|
|
|
|
```bash
|
|
# From Hetzner console or another access method:
|
|
journalctl -b -u tailscaled | grep -E "SetNetworkUp|link state|error|DERP"
|
|
# Look for:
|
|
# magicsock: SetNetworkUp(false)
|
|
# link state: interfaces.State{defaultRoute= ifs={} v4=false v6=false}
|
|
# health: Tailscale could not connect to any relay server
|
|
```
|
|
|
|
### Fix
|
|
|
|
Deploy a systemd drop-in to wait for full network connectivity:
|
|
|
|
```ini
|
|
# /etc/systemd/system/tailscaled.service.d/override.conf
|
|
[Unit]
|
|
After=network-online.target
|
|
Wants=network-online.target
|
|
```
|
|
|
|
Then reload and restart:
|
|
|
|
```bash
|
|
systemctl daemon-reload
|
|
systemctl restart tailscaled
|
|
```
|
|
|
|
### Affected Hosts
|
|
|
|
All hosts where Tailscale is the primary access path. Particularly impactful on VPS hosts with slow interface bringup. Both Fedora and Ubuntu hosts are affected.
|
|
|
|
---
|
|
|
|
## Prevention
|
|
|
|
- Set root passwords on all VPS hosts for emergency console access
|
|
- Ansible playbooks deploy both fixes automatically:
|
|
- `configure_tailscale_network_wait.yml` — tailscaled network-online dependency (all hosts)
|
|
- `configure_tailscale_ssh_only.yml` — ssh.socket Tailscale dependency (Ubuntu only)
|
|
|
|
## References
|
|
|
|
- [[dcaprod#2026-05-19 — SSH unreachable due to ssh.socket race condition with Tailscale]]
|
|
- [[majordiscord#2026-05-19 — Tailscale boot race: unreachable after Ansible reboot]]
|
|
- [[majorlinux#2026-05-19 — ssh.socket override patched: added Tailscale dependency]]
|
|
- [[dcaprod#2026-05-23 — SSH unreachable again: BindsTo ordering cycle in ssh.socket override]]
|
|
- [[majorlinux#2026-05-31 — ssh.socket race recurrence post-reboot (Requires= insufficient; added wait-ready gate)]]
|
|
- [[majortoot#2026-05-31 — ssh.socket race post-reboot on majortoot-hetzner (during cutover night)]]
|
|
- Ansible: `configure_tailscale_ssh_only.yml`, `configure_tailscale_network_wait.yml`
|