lockf: don't hold stdin/stdout/stderr open

[kevans]

Summary

None of these are essential in the lockf monitor (parent post-fork), so
close them to maintain the illusion that lockf hasn't been inserted into
the pipeline. This ensures that the correct effects happen on other
programs in the pipeline if the locked command closes or redirects these
elsewhere.

The original patch used -s to close stdout/stderr rather than closing
them unconditionally, but it's not clear that we really care that much.

PR: 112379
Sponsored by: Klara, Inc.

[0mp]

It seems like the commit message should contain "Reported by". The reference to "the original patch" is a bit unclear as well. It took me a moment to figure out that this is pointing at the patch from the PR.

Perhaps the commit message could contain the example from the Bugzilla PR, i.e., (script1.sh | lockf foo script2.sh 2>&1 &) | mail -s something somewhere.

usr.bin/lockf/lockf.c

164

Didn't the old err contain more details?

[allanjude]

reviewed-by: allanjude

[des]

usr.bin/lockf/lockf.c

164

sure but there is no stderr at this point.

[des]

usr.bin/lockf/lockf.c

216

stderr is almost certainly closed at this point.

[kevans]

stderr will almost always be closed when killed is called, so just exit.

[kevans]

usr.bin/lockf/lockf.c

164

I note that there's very little failure mode left with waitpid() anyways when used in this manner, so I wasn't too concerned about working out some gymnastics to try and make it more debuggable looking.