iroh
iroh copied to clipboard
n0-computer
Always delete an UDS file before binding it
The RAII struct UdsGuard works well when the binary terminates normally but this is unfortunately not always the case:
- crashes.
- on Android, daemons restarted by the init system.
- power loss on mobile devices.
To avoid these failures, this patch forces the deletion before trying to bind the socket. This means that we don't really need the UdsGuard anymore - let me know if I should also remove it. cc @dignifiedquire
I don’t think unconditionally deleting these is a good idea, because now you break an already running system if you run the binary twice, instead of erroring out.
Thoughts @fabricedesre ? This is tricky, any idea how other applications typically do this?
Thoughts @fabricedesre ? This is tricky, any idea how other applications typically do this?
I've seen 2 approaches:
- use a file containing the PID of the running instance. In theory this can be racy, in practice that works well. In iroh we could provide that to all programs with a helper in iroh-utils.
- scan /proc/$pids/cmdline or equivalent to find an already running instance. It's quite tedious and can be slow, and OS specific.
use a file containing the PID of the running instance. In theory this can be racy, in practice that works well. In iroh we could provide that to all programs with a helper in iroh-utils.
kubo uses lockfiles, and while they're super tedious, I think this is the best approach we have. I agree they're only really racy in theory. Cleaning them up in all cases including program crashes is the hard part in my humble experience.
This problem is everywhere. For heaven's sake, Microsoft Word can't get around this
Word creates an owner file when you open a previously saved Word document. An owner file is temporary and holds the logon name of the person who opens the document.
I'd vote for a lockfile with PID of running process.
Cleaning them up in all cases including program crashes is the hard part in my humble experience.
Having the pid in the lock file allows you to ignore / override it after a crash because you can check that the pid is actually one of a running process. Of course pid reuse is a thing, but well...
I can take that bug if that helps.
On linux at least fcntl works pretty well I believe, as the OS releases the lock when the process dies
I forgot about it because I kept it in my fork, so feel free to close. It likely less of an issue now with the lock files.