When I see a bunch of `write: broken pipe ` errors for a process what does it mean ?
Clash Royale CLAN TAG#URR8PPP
up vote
1
down vote
favorite
When I see a bunch of write: broken pipe errors for a process what does it mean ?
level=error msg="attach: stdout: write unix /var/run/docker.sock->@: write: broken pipe"
Does this mean this process needs more file descriptors ? or any other resource ? which way should I be looking at ?
linux docker socket
asked Nov 16 at 21:25
user2062360
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
add a comment |
up vote
1
down vote
favorite
When I see a bunch of write: broken pipe errors for a process what does it mean ?
level=error msg="attach: stdout: write unix /var/run/docker.sock->@: write: broken pipe"
Does this mean this process needs more file descriptors ? or any other resource ? which way should I be looking at ?
linux docker socket
asked Nov 16 at 21:25
user2062360
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
usually it meanssomeprogramin aprogram | someprogramtype of pipe has gone away whileprogramwas writing to that pipe
– thrig
Nov 16 at 22:19
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
When I see a bunch of write: broken pipe errors for a process what does it mean ?
level=error msg="attach: stdout: write unix /var/run/docker.sock->@: write: broken pipe"
Does this mean this process needs more file descriptors ? or any other resource ? which way should I be looking at ?
linux docker socket
asked Nov 16 at 21:25
user2062360
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
When I see a bunch of write: broken pipe errors for a process what does it mean ?
level=error msg="attach: stdout: write unix /var/run/docker.sock->@: write: broken pipe"
Does this mean this process needs more file descriptors ? or any other resource ? which way should I be looking at ?
linux docker socket
linux docker socket
asked Nov 16 at 21:25
user2062360
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 16 at 21:25
user2062360
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 16 at 21:25
user2062360
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
asked Nov 16 at 21:25
user2062360
61
asked Nov 16 at 21:25
user2062360
61
61
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
New contributor
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
user2062360 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.
1
usually it meanssomeprogramin aprogram | someprogramtype of pipe has gone away whileprogramwas writing to that pipe
– thrig
Nov 16 at 22:19
add a comment |
1
usually it meanssomeprogramin aprogram | someprogramtype of pipe has gone away whileprogramwas writing to that pipe
– thrig
Nov 16 at 22:19
1
1
usually it means
someprogram in a program | someprogram type of pipe has gone away while program was writing to that pipe– thrig
Nov 16 at 22:19
usually it means
someprogram in a program | someprogram type of pipe has gone away while program was writing to that pipe– thrig
Nov 16 at 22:19
add a comment |
1 Answer
1
active
oldest
votes
up vote
3
down vote
It means that someone has set the signal handler for SIGPIPE to SIG_IGN (ignore), and the error (trying to write into a pipe with no reader) is reported instead via the exit status of write(2).
In your case, the program at the other end of the Unix socket is most probably crashing or exiting unexpectedly. I'll look first into that.
It may be some sofisticated attack -- many badly written programs don't expect errors from write(2) and do not check its return value.
A process exiting because of a SIGPIPE is nothing special, and it's how things should work. This is how command | head -5 works; if command still wants to write stuff into the pipeline after head -5 has exited, it will receive a SIGPIPE, and everything will finely terminate. But if command installs a signal handler for SIGPIPE, or if the calling shell has set a trap '' PIPE (which will cause itself and its children to ignore the SIGPIPE signal), any write(2) into the pipe will return -1 with errno set to EPIPE ("broken pipe"). And sockets work the same as pipes in this regard.
answered Nov 16 at 22:25
mosvy
4,305221
1
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
3
down vote
It means that someone has set the signal handler for SIGPIPE to SIG_IGN (ignore), and the error (trying to write into a pipe with no reader) is reported instead via the exit status of write(2).
In your case, the program at the other end of the Unix socket is most probably crashing or exiting unexpectedly. I'll look first into that.
It may be some sofisticated attack -- many badly written programs don't expect errors from write(2) and do not check its return value.
A process exiting because of a SIGPIPE is nothing special, and it's how things should work. This is how command | head -5 works; if command still wants to write stuff into the pipeline after head -5 has exited, it will receive a SIGPIPE, and everything will finely terminate. But if command installs a signal handler for SIGPIPE, or if the calling shell has set a trap '' PIPE (which will cause itself and its children to ignore the SIGPIPE signal), any write(2) into the pipe will return -1 with errno set to EPIPE ("broken pipe"). And sockets work the same as pipes in this regard.
answered Nov 16 at 22:25
mosvy
4,305221
1
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
add a comment |
up vote
3
down vote
It means that someone has set the signal handler for SIGPIPE to SIG_IGN (ignore), and the error (trying to write into a pipe with no reader) is reported instead via the exit status of write(2).
In your case, the program at the other end of the Unix socket is most probably crashing or exiting unexpectedly. I'll look first into that.
It may be some sofisticated attack -- many badly written programs don't expect errors from write(2) and do not check its return value.
A process exiting because of a SIGPIPE is nothing special, and it's how things should work. This is how command | head -5 works; if command still wants to write stuff into the pipeline after head -5 has exited, it will receive a SIGPIPE, and everything will finely terminate. But if command installs a signal handler for SIGPIPE, or if the calling shell has set a trap '' PIPE (which will cause itself and its children to ignore the SIGPIPE signal), any write(2) into the pipe will return -1 with errno set to EPIPE ("broken pipe"). And sockets work the same as pipes in this regard.
answered Nov 16 at 22:25
mosvy
4,305221
1
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
add a comment |
up vote
3
down vote
up vote
3
down vote
It means that someone has set the signal handler for SIGPIPE to SIG_IGN (ignore), and the error (trying to write into a pipe with no reader) is reported instead via the exit status of write(2).
In your case, the program at the other end of the Unix socket is most probably crashing or exiting unexpectedly. I'll look first into that.
It may be some sofisticated attack -- many badly written programs don't expect errors from write(2) and do not check its return value.
A process exiting because of a SIGPIPE is nothing special, and it's how things should work. This is how command | head -5 works; if command still wants to write stuff into the pipeline after head -5 has exited, it will receive a SIGPIPE, and everything will finely terminate. But if command installs a signal handler for SIGPIPE, or if the calling shell has set a trap '' PIPE (which will cause itself and its children to ignore the SIGPIPE signal), any write(2) into the pipe will return -1 with errno set to EPIPE ("broken pipe"). And sockets work the same as pipes in this regard.
answered Nov 16 at 22:25
mosvy
4,305221
It means that someone has set the signal handler for SIGPIPE to SIG_IGN (ignore), and the error (trying to write into a pipe with no reader) is reported instead via the exit status of write(2).
In your case, the program at the other end of the Unix socket is most probably crashing or exiting unexpectedly. I'll look first into that.
It may be some sofisticated attack -- many badly written programs don't expect errors from write(2) and do not check its return value.
A process exiting because of a SIGPIPE is nothing special, and it's how things should work. This is how command | head -5 works; if command still wants to write stuff into the pipeline after head -5 has exited, it will receive a SIGPIPE, and everything will finely terminate. But if command installs a signal handler for SIGPIPE, or if the calling shell has set a trap '' PIPE (which will cause itself and its children to ignore the SIGPIPE signal), any write(2) into the pipe will return -1 with errno set to EPIPE ("broken pipe"). And sockets work the same as pipes in this regard.
answered Nov 16 at 22:25
mosvy
4,305221
edited 2 days ago
answered Nov 16 at 22:25
mosvy
4,305221
answered Nov 16 at 22:25
mosvy
4,305221
answered Nov 16 at 22:25
mosvy
4,305221
4,305221
1
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
add a comment |
1
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
1
1
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
Never attribute to malice that...
– Rui F Ribeiro
2 days ago
add a comment |
user2062360 is a new contributor. Be nice, and check out our Code of Conduct.
user2062360 is a new contributor. Be nice, and check out our Code of Conduct.
user2062360 is a new contributor. Be nice, and check out our Code of Conduct.
user2062360 is a new contributor. Be nice, and check out our Code of Conduct.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f482250%2fwhen-i-see-a-bunch-of-write-broken-pipe-errors-for-a-process-what-does-it-me%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
usually it means
someprogramin aprogram | someprogramtype of pipe has gone away whileprogramwas writing to that pipe– thrig
Nov 16 at 22:19