Skip to content

ss used in scripts/deploy-remote.sh is not available on macOS #310

Description

@amcfague

Summary

scripts/deploy-remote.sh relies on ss (iproute2) to check listening ports and resolve PIDs. ss is Linux-only — it is not available on macOS/OSX and cannot be installed there — so any of these code paths that execute on a developer's Mac will fail or silently misbehave.

Occurrences

All in scripts/deploy-remote.sh:

  • Line 320! ss -tlnp | grep -q ':8080\b' — wait for the controller to stop.
  • Line 335if ss -tlnp | grep -q ':8080\b'; then — detect port 8080 still in use.
  • Line 337ss -tlnp | grep ':8080\b' >&2 || true — diagnostic dump of 8080 listeners.
  • Line 348controller_pid=$(remote "ss -tlnp | sed -n '...pid=...' | head -1" ...) — resolve controller PID.
  • Line 451if ss -tlnp 2>/dev/null | grep -q ":${port}\b"; then — port-based service status check.

Notes

  • These usages currently run inside remote/<<'REMOTE' heredoc blocks targeting the Linux host, where ss exists, so they work today. However, the pattern is fragile: any refactor that runs these checks locally (or reuse of these snippets in a local script) will break on macOS, and the dependency on ss is not obvious from the call sites.
  • macOS provides no drop-in equivalent for ss -tlnp.

Suggested fix

Use a portable alternative that works on both Linux and macOS, e.g. lsof:

lsof -nP -iTCP:8080 -sTCP:LISTEN
lsof -ti tcp:8080 -sTCP:LISTEN   # PIDs only

Alternatively, guard ss usage so it is only ever invoked on the remote host and never locally, and document that assumption.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions