| 1 |
Mick wrote: |
| 2 |
>> File "/usr/lib64/python2.7/SocketServer.py", line 694, in finish |
| 3 |
>> self.wfile.flush() |
| 4 |
>> File "/usr/lib64/python2.7/socket.py", line 303, in flush |
| 5 |
>> self._sock.sendall(view[write_offset:write_offset+buffer_size]) |
| 6 |
>> error: [Errno 32] Broken pipe |
| 7 |
>> ---------------------------------------- |
| 8 |
>> |
| 9 |
> I'm pretty much clueless in python so can't interpret the messages - |
| 10 |
> hopefully someone more knowledgeable will chime in. |
| 11 |
> |
| 12 |
'Broken pipe' just means the remote closed the connection. It's a pretty |
| 13 |
standard error in this context, which the server should handle. |
| 14 |
|
| 15 |
A process normally gets a SIGPIPE which will by default terminate it, which |
| 16 |
is what you want if you have a pipeline'd command whose output is no longer |
| 17 |
required. An example would be checking there is at least one matching file |
| 18 |
somewhere in a directory hierarchy with: |
| 19 |
read -d '' f < <(find /base/dir -type f -name 'foo*' -print0) |
| 20 |
[[ $f ]] || echo 'no foo* files' |
| 21 |
|
| 22 |
-- find will terminate after the first filename has been read. |
| 23 |
|
| 24 |
In this case, signal(SIGPIPE, SIG_IGN) or the equivalent has been called, |
| 25 |
which gives EPIPE instead; a process ignoring the signal is supposed to deal |
| 26 |
with the error. So I'd say it's a bug. |
| 27 |
|
| 28 |
-- |
| 29 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives