On 2022-03-06, Arthur Williams <[email protected]> wrote: > Yeah I noticed that it wasn't defined in POSIX (which makes me wounder > why it is here in sbase and not ubase). To clarify what I meant, there > are popular implementations that don't have the '-F' flag (like busybox) > and adding it would just encourage people to write code that didn't work > in many environments. And this may be fine if there was some benefit, > but I just don't see the any positives of forking. > > But if we agree it isn't incorrect to not fork, any objection to the > patch?
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. - 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. 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. 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.
