15 hours ago
A read-only metadata safety check in the Railway console found a live ancestor process with a regular executable whose executable link was marked deleted. Our no-deleted-executable guard stopped before the workload ran. The ancestor’s identity and provenance are unknown. The console session later ended, and we have not reconnected or taken remedial action.
Could an intentional memory-backed helper or an unlinked/replaced console helper cause this observation? Who maintains the console launch chain and helper lifecycle, and is there documentation explaining this behavior?
What documented, supported console or execution arrangement would let us run the check while preserving the unchanged no-deleted-executable guard? We are looking for a supported path that satisfies the guard, without disabling it or making an exception.
1 Replies
Status changed to Awaiting Railway Response Railway • about 15 hours ago
14 hours ago
This thread has been opened as a bounty so the community can help solve it.
Status changed to Open Railway • about 14 hours ago
2 hours ago
Short version: don't run the check from the dashboard console. Run it in a process tree you own, so every ancestor is something your image put there.
Why the guard tripped: the web console is an interactive shell that Railway attaches to a running container. Its launch chain sits above your shell and isn't part of your image, so your guard can't vouch for it. Only Railway staff can confirm what that specific helper is and why its executable link shows as deleted. For your purposes, the safe reading is that it's outside your control, which is exactly what the guard is designed to catch.
Supported ways to run the check with the guard unchanged:
- Pre-deploy command (best for a one-off gate)
It runs between build and deploy in its own container, with your env vars and private network. A non-zero exit stops the deployment, so the guard becomes a real gate:
{
"$schema": "https://railway.com/railway.schema.json",
"deploy": {
"preDeployCommand": ["./bin/safety-check"]
}
}
One limit: pre-deploy can't read or write the volume. If the check needs the volume, use option 2.
- Start command wrapper (when the check needs the runtime filesystem)
Run the check first, then exec your app. With a Dockerfile or image, the start command overrides ENTRYPOINT in exec form, so the check's ancestry is just your own entrypoint:
/bin/sh -c "./bin/safety-check && exec your-app"
If the check fails, the deploy fails its healthcheck instead of running the workload.
- railway ssh (only if you need it interactive)
This goes through ssh.railway.com, so it's still a Railway-managed launch path. I'd expect the guard to need the same scrutiny there, which is why options 1 and 2 are the ones that fully meet "no exception, no disabling."
Docs:
https://docs.railway.com/deployments/pre-deploy-command
https://docs.railway.com/deployments/start-command
https://docs.railway.com/config-as-code/reference
If you share whether the check needs the volume, I can tell you which of the two fits.