Because lockf command forks but doesn't close input and output file handles
in the main process, closing stdin, stdout or stderr inside child processes
doesn't cause respective ends of pipes seen as closed by programs that read
write to them.
(script1.sh | lockf foo script2.sh 2>&1 &) | mail -s something somewhere
Suppose that script2.sh closes its standard input and continues some long-time
processing before script1.sh completes writing to its stdndard output.
script1.sh will hang for a long time (it would not without lockf).
As a more practical example, script2.sh redirects its output at some point
and continues its business. Because of lockf, mail will needlessly wait until
I think that stdin should always be closed, and -s switch may be used as a flag
that closing stdout and stderr is desirable.
Fix: This is a patch against src/usr.bin/lockf/lockf.c,v 22.214.171.124
For bugs matching the following criteria:
Status: In Progress Changed: (is less than) 2014-06-01
Reset to default assignee and clear in-progress tags.
Mail being skipped