Undocumented issue: Open system call blocks on named pipes (and a feature request)
cs at cskk.id.au
Fri Dec 28 18:37:14 EST 2018
On 28Dec2018 20:21, Daniel Ojalvo <D.Ojalvo at F5.com> wrote:
>I agree that previous behavior shouldn't be changed, but I would
>suggest updating the documentation to point it out as a footnote. The
>current behavior is correct just unclear. Most people just learning
>about the open command wouldn't have this expectation.
Maybe, maybe not. "Most" is a conjecture. IMO people will only find it
surprising if they think any filesystem object can be instantly opened.
However that is a misapprehension on their part.
My personal expectation is that open() will come back when the object is
open. I don't have a timeframe in mind unless I have a strong
expectation about _what_ I'm opening.
>I came across the issue when I had a program that would open up all the
>files in a directory to read a few bytes from the beginning. My concern
>would be someone just making a named pipe over a file that a program
What about a symlink to a magic /dev/tcp/host:port device, initiating a
TCP connection? Particularly if "host" is down or inaccessible? Etc.
>Arguably, anyone affected by that would be shooting themselves in the
>foot to begin with, but I think there are "security" concerns because
>someone could cause a bit of mischief that would be difficult to
It isn't hard to diagnose at all. Point strace at the hung pogram, see
it is opening some path, "ls -ld the-path", oooh, it isn't a regular
The point here is that if a programme opens every file in a directory,
maybe it should constrain itself to regular files. Opening anything else
may not just hang, it can have real world side effects. (Usually such
effect happen at some point after open, for example opening a rewind
take device will physicially rewind the tape on close, but you've
committed to that happening by opening it in the first place.)
I think Chris offered the example of a subdirectory to suggest that such
a programme already has an opnion about what to open and what to leave
alone (unless is _does_ open() subdirectories, which might be useful but
is usually misleading and on some OSes unsupported). So the programme
should be pickier anyway.
>That all being said, I think I would like to put in a feature request
>for a non-blocking option. How should I go about doing so?
I agree with the suggestion already made: devise a well thought out
proposal which fits nicely with the existing open() call (eg an addition
to the mode argument or something), and describe it clearly in
Certainly a number of things can be opened in a "nonblocking" mode,
which means that reads return instantly if there's no available data, so
having an open not block isn't unreasonable to want. But it may be
unreasonable to implement in general: OSes may not support it directly.
Cameron Simpson <cs at cskk.id.au>
More information about the Python-list