On Sun, Mar 06, 2022 at 03:14:00PM -0800, Michael Forney wrote: > There are a couple of cases I can think of where not forking might not > be what you want: > - If the process forks again and then exits, the new child ends up > holding on to the lock longer than the lifetime of the original > process. There seems to be a -o flag to close the lock before execing > the child to prevent this, but this doesn't work if we exec directly.
> The first point made me realize that -o with your patch makes flock(1) > a no-op. It would take the lock, then release it, and then exec. So if > we were to apply the patch, I think we'd need to remove the -o option. Why thank you for answering why '-o' exists. I was originally fine with getting rid of '-o' too, but the usecase you present seems relevant enough. > - It's debatable whether this is a valid thing to do, but if the > process tries to close all open file descriptors (using something like > closefrom on OpenBSD), it might end up releasing the lock > accidentally. Sounds plausible. I can see why people may want to not let the command implicitly release its lock. > Did you check what other implementations of flock(1) do in terms of > forking, and what options they support? It looks like in addition to > busybox, NetBSD and FreeBSD both have it. I have now. Seems like everyone forks and like half (util-linux and FreeBSD) provide the -F option. OK you've convinced me that there is reason to keep forking and that the current behavior of flock is fine. Thanks, Arthur
