Bug 112379 - [patch] [request] lockf(1): on closing stdin, stdout, stderr
Summary: [patch] [request] lockf(1): on closing stdin, stdout, stderr
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-05-03 06:50 UTC by Alexander Melkov
Modified: 2017-12-31 22:37 UTC (History)
0 users

See Also:


Attachments
file.diff (486 bytes, patch)
2007-05-03 06:50 UTC, Alexander Melkov
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Alexander Melkov 2007-05-03 06:50:04 UTC
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.

For example:
(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
script2.sh completes.

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 1.11.8.1
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:58:59 UTC
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