App: legtracker · Org: Karim Alayli (personal) · Region: yyz
Machines: 8d10e1a62173e8 (since destroyed), 861922f5924d38 (current)
Process group: cron — no services; runs a Django management-command scheduler loop (“python manage.py ingest_loop”)
Our cron machine is stopped by the platform at exactly t+300s after every start — three observed occurrences across two machines and three start methods (deploy-created, fly machine start, manual start during a controlled observation). Every stop: SOURCE=flyd, exit_code=130, oom_killed=false, requested_stop=true.
Live config of the current machine (fly machine status --display-config, key excerpt, captured minutes before the third occurrence):
{ “schedule”: null, “standbys”: null, “services”: null, “checks”: null,
“auto_destroy”: null, “restart”: { “policy”: “always” },
“kill_timeout”: null, “stop_config”: null }
The three occurrences
Jul 8 — machine 8d10e1a62173e8 (created by fly deploy):
stopped exit flyd 2026-07-08T16:40:42.622-04:00 exit_code=130,oom_killed=false,requested_stop=true
stopping stop flyd 2026-07-08T16:40:41.784-04:00
started start flyd 2026-07-08T16:35:41.781-04:00
starting start user 2026-07-08T16:35:40.592-04:00
→ start 16:35:41.781, stop request 16:40:41.784 = t+300.003s
Jul 14 — machine 861922f5924d38, first window (machine created 7 seconds before starting):
stopped exit flyd 2026-07-14T15:58:56.831-04:00 exit_code=130,oom_killed=false,requested_stop=true
stopping stop flyd 2026-07-14T15:58:55.701-04:00
started start flyd 2026-07-14T15:53:55.697-04:00
created launch user 2026-07-14T15:53:48.845-04:00
→ start 15:53:55.697, stop request 15:58:55.701 = t+300.004s
Jul 14 — same machine, controlled observation with logs/events streamed:
stopped exit flyd 2026-07-14T17:34:07.893-04:00 exit_code=130,oom_killed=false,requested_stop=true
stopping stop flyd 2026-07-14T17:34:07.151-04:00
started start flyd 2026-07-14T17:29:07.149-04:00
starting start user 2026-07-14T17:29:05.924-04:00
→ start 17:29:07.149, stop request 17:34:07.151 = t+300.002s
Ruled out by observation
- Proxy idle-stop: the machine has no services (verified in live config); stop SOURCE is flyd; the interval is a fixed 300s timer regardless of activity.
- Scheduled machine / standby linkage / health checks / auto_destroy / stop_config / kill_timeout: all null in live config (above).
- Guest crash or self-exit: requested_stop=true on every event; guest logs across minute five show the process healthy (mid-sleep in its scheduler loop) until SIGINT arrives.
- Stale machine config: the Jul 14 machine was freshly created by that day’s deploy and died at t+300s on its first start, seven seconds after creation.
- Our own automation: all stop events carry SOURCE=flyd, not user; no API tokens of ours were active at those timestamps.
- Restart-policy interplay: understood that restart policies don’t apply to requested stops — we’re not asking to resurrect the machine, we’re asking to remove the stopper.
We can reproduce this on demand: it fires deterministically at t+300s on every start.
THE QUESTION: what platform mechanism issues a requested_stop at exactly t+300s to a machine with no services, schedule, standbys, checks, auto_destroy, or stop_config? What desired-state does flyd hold for this machine, why, in which config or API field can we see it, and how do we disable it?