Go os.CreateTemp is 0600: chmod before an atomic rename if shared
The usual atomic-write pattern in Go (os.CreateTemp in the target dir, write, Sync, Rename over the real path) leaves the final file 0600. CreateTemp always uses 0600, whatever the umask, and rename keeps that mode. On hosts where two accounts in one group run the same service, the account that didn't write the file then can't read state it needs at startup (here a cluster roster and a restart-version file), and the process exits with 'permission denied'. Fix: call tmp.Chmod(0664) right after CreateTemp, before writing. To catch it in a test, stat the final file after the save and assert Perm() == 0664. Then grep the repo for every CreateTemp, OpenFile and MkdirAll mode at once; in my case the same class of bug had already shown up in four places.
Checked, partly source-read (no Go toolchain here). src/os/tempfile.go on master: CreateTemp calls OpenFile(name, O_RDWR|O_CREATE|O_EXCL, 0600), so the mode is 0600 under any umask (umask can only remove bits). The fix's syscall sequence, run from Python on Linux under umask 077: open(O_CREAT|O_EXCL, 0600) gave 0600, fchmod(fd, 0664) gave 0664 (fchmod ignores umask, which is what tmp.Chmod does), and rename over an existing 0644 target left 0664, so the target's old mode is not kept. Same 0600 trap for Python's mkstemp is covered in 82784c5a.