Self-hosted MAC OS runner has error No route to host via curl (when using svc.sh )

[ajax-koval-i]

Why are you starting this discussion?

Question

What GitHub Actions topic or product is this about?

Actions Runner

Discussion Details

When I start my action runner process via run.sh all works fine
But when i start action process via service (svc.sh) I have an error, you can see below.
How can i fix it
I think problem in launchd process that start runner listener and worker, but i am not shure

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0* Trying 10.18.141.14:8001...

• Immediate connect fail for 10.18.141.14: No route to host

• Failed to connect to 10.18.141.14 port 8001 after 0 ms: Couldn't connect to server

  0 0 0 0 0 0 0 0 --:--:-- --:--:-- --:--:-- 0

• Closing connection
  curl: (7) Failed to connect to 10.18.141.14 port 8001 after 0 ms: Couldn't connect to server

[DavitEgoian]

Quick things to check (do these from the mac where it fails):

Run these from a normal shell (where ./run.sh works) and from an elevated/svc context (or while service is running) and compare results. This shows whether it’s a routing/proxy/permission difference:

ping -c 3 10.18.141.14
route get 10.18.141.14
curl -v http://10.18.141.14:8001/

If the service is starting at boot you may not see the network route yet; check logs from the runner (_diag folder) and macOS system logs:

tail -n 200 ./_diag/*.log
log show --predicate 'process == "Runner.Listener"' --last 1h

If curl works interactively but immediately fails under svc.sh, likely causes are: launchd starts before network is up, missing HTTP(S)_PROXY/NO_PROXY in the service environment, macOS local-network privacy blocking the service binary, or firewall/routing differences when run as another user. Community reports point to privacy/network changes in macOS and to svc.sh/launchd oddness.

Common fixes that work for others:

1. Make the service wait for network before starting. Easiest quick fix: wrap the runner start in a small script that waits until target is reachable, then starts the runner. Example:

#!/bin/bash
until curl -sS --max-time 2 http://10.18.141.14:8001/ >/dev/null 2>&1; do
  sleep 2
done
./run.sh

Install that wrapper as the command launchd runs (or modify svc.sh install to call it). This avoids race conditions on boot.

2. Check and export proxy and env vars for the service. svc.sh/launchd won’t inherit your interactive shell’s env. If you need a proxy, add HTTP_PROXY/HTTPS_PROXY/NO_PROXY into the launchd plist or into a wrapper script so the service sees them. Community threads show proxy issues triggering similar failures.

3. macOS local network privacy (Sequoia/15.x): some users reported “No route to host” because the service binary never got the local network permission prompt when launched by launchd. Try running the runner interactively one time as the same user so macOS shows the local network access dialog and allow it, or check System Settings → Privacy & Security → Local Network for the runner binary. If you suspect this, running the binary interactively (or using a LaunchAgent under the logged-in user instead of LaunchDaemon) often fixes it.

4. Reinstall the service carefully and check launchctl errors. Run:

./svc.sh uninstall
./svc.sh install
sudo launchctl bootstrap /Library/LaunchDaemons/<your-plist>.plist
sudo launchctl start <label>
sudo launchctl list | grep runner

If launchctl returns errors, they often point to missing entitlements or I/O issues.

If you want a fast workaround, use a LaunchAgent (runs as logged-in user) or the wrapper-wait approach — several guides recommend LaunchAgent as more reliable for mac GUI/macOS runner setups.

If you want, I can:
• produce a ready-to-install wrapper script + a small launchd plist that waits for network, or
• look at your svc.sh logs if you paste the relevant _diag logfile lines and the output of route get 10.18.141.14 and log show results — that’ll help pinpoint whether it’s route/proxy/permission.

[ajax-koval-i]

Bro, really thanks you for fast answer
I connected via GUI and enable toggles for Node and Runner binaries.
It was a reason

macOS local network privacy (Sequoia/15.x): some users reported “No route to host” because the service binary never got the local network permission prompt when launched by launchd. Try running the runner interactively one time as the same user so macOS shows the local network access dialog and allow it, or check System Settings → Privacy & Security → Local Network for the runner binary. If you suspect this, running the binary interactively (or using a LaunchAgent under the logged-in user instead of LaunchDaemon) often fixes it.