Closed jamilbk closed 1 week ago
Will look into it after #4899
I thought maybe systemctl start
is returning before our tunnel interface is all the way up. When it passes, this resolvectl dns tun-firezone
prints the sentinel https://github.com/firezone/firezone/actions/runs/9006458384/job/24744284872#step:6:65
But systemctl start
is supposed to wait for us to notify systemd that we're ready, and we only do that if we're running as an IPC service (not applicable) or right after we configure DNS.
Maybe the DNS configuration is secretly async on the inside. I'll add some debug logs as the next step
Happened again, but debug_exit
didn't do what I needed: https://github.com/firezone/firezone/actions/runs/9009905220/job/24755105430
Fixed by #4962
Still happening. https://github.com/firezone/firezone/actions/runs/9290693824/job/25567691838
PR #5111 will move the systemd notification up to the Client so maybe that will give us more control over it.
Another replication https://github.com/firezone/firezone/actions/runs/9469788060/job/26089691139 In this case the DNS didn't get controlled even though our logs indicate we thought it had https://github.com/firezone/firezone/actions/runs/9469788060/job/26089691139#step:6:93
Still happening - #5911
This call to sd_notify
happens way too early: https://github.com/firezone/firezone/blob/bf693ad83f2fedf2380a843311c05538318b9598/rust/headless-client/src/standalone.rs#L186
That may not be the only root cause, but it's not helping anything.
That PR may not have main
merged
Nah it's got the sleep :-(
https://github.com/firezone/firezone/actions/runs/10080667883/job/27871200510#step:5:19
Fixed? Not seen this one in a while.
main
2 days after Jamil's last comment, so that could explain itWill close for now
https://github.com/firezone/firezone/actions/runs/9006460494/job/24744332707
Seen this one happen a few times. Maybe a timing issue / race condition that a sleep could fix?