Which os.OpenFile flags make a daemon's lockfile creation fail if the file already exists?

### The flags ```go f, err := os.OpenFile(lockPath, os.O_CREATE|os.O_EXCL|os.O_WRONLY, 0o644) if errors.Is(err, fs.ErrExist) { return fmt.Errorf("another instance is already running") } if err != nil { return err } ``` `os.O_CREATE` says "make the file if it is not there". On its own it is happy to reuse an existing file. `os.O_EXCL` changes that pairing into "make the file, and fail if it is already there". `O_EXCL` is defined only in combination with `O_CREATE`; on its own it does nothing useful, and code that passes it alone is confused about what it does. The value of the pair is that the operating system performs the existence test and the creation as one indivisible operation. Two processes that reach that line at the same instant do not both succeed. Exactly one gets a handle; the other gets an error. Any Go code that instead asks whether the path exists and then creates it has separated those two steps, and something else can create the file in the gap. ### Recognising the loser's error `os.OpenFile` returns `*fs.PathError`, a struct with `Op`, `Path` and a wrapped `Err`. The wrapped value for this case is the platform's file-exists error, which the standard library maps to the sentinel `fs.ErrExist` (also reachable as `os.ErrExist`, the same value). Because the sentinel is wrapped rather than returned directly, `err == fs.ErrExist` is false and `errors.Is(err, fs.ErrExist)` is true. Matching on `err.Error()` containing the word "exists" is wrong for the same reasons it is always wrong: the text is platform-specific and not part of any contract. ### What a lockfile actually guarantees This is where candidates who have only read about the flags separate from candidates who have operated a daemon. Exclusive creation gives you mutual exclusion **over the existence of a name**, not over a running process. Concretely: - The file has no association with the process that made it. Nothing removes it when that process dies. - A clean shutdown can delete it with `os.Remove`, but a `SIGKILL`, an OOM kill, or a power loss cannot run that code. - After such a death, every subsequent start finds the file and refuses to run, which is an outage that looks like a bug in the daemon rather than in the lock. The usual mitigations are to write the pid (and often the boot id or start time) into the file after creating it, so a later start can decide whether the recorded process is still alive, and to document a manual override. The alternative is a real advisory lock from the operating system, which the kernel releases when the descriptor closes for any reason including a crash — but Go's standard library exposes no portable API for that, so it means platform-specific code. One more caveat worth knowing: the atomicity of exclusive create is a property of the filesystem, and it has historically not been reliable over some network filesystems. A lockfile on a shared network mount is a weaker guarantee than the same code on a local disk. ### Why not os.Create `os.Create` is `O_RDWR|O_CREATE|O_TRUNC`. Used as a lock it fails twice over. It succeeds when the file already exists, so both instances think they hold the lock, and its `O_TRUNC` empties the file — destroying the pid the current holder wrote there. The whole point of the exclusive flag is that the call is allowed to fail, and a candidate who reaches for a call that cannot fail has not understood the requirement. ### The same pattern beyond lockfiles Exclusive create is the general Go idiom for "claim a name": one worker in a pool claiming a unit of work by creating a marker file, a first-run initialisation that must happen once, a cache entry that must not be written twice. In each case the semantics you are buying are the same — the create either wins or reports `fs.ErrExist` — and the same caveats about crash recovery apply. Whenever the claim must be released automatically on process death, a file whose only property is existence is the wrong primitive.