You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@zookeeper.apache.org by "Stephen Tyree (JIRA)" <ji...@apache.org> on 2011/08/23 20:30:29 UTC
[jira] [Updated] (ZOOKEEPER-1051) SIGPIPE in Zookeeper 0.3.* when
send'ing after cluster disconnection
[ https://issues.apache.org/jira/browse/ZOOKEEPER-1051?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Stephen Tyree updated ZOOKEEPER-1051:
-------------------------------------
Attachment: ZOOKEEPER-1051.patch
Patch which fixes the issue for Linux and Linux alone. Do we support Zookeeper for other *nixes? If so, there are likely to be platform specific solutions to the problem for them as well.
> SIGPIPE in Zookeeper 0.3.* when send'ing after cluster disconnection
> --------------------------------------------------------------------
>
> Key: ZOOKEEPER-1051
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-1051
> Project: ZooKeeper
> Issue Type: Bug
> Components: c client
> Affects Versions: 3.3.2, 3.3.3, 3.4.0
> Reporter: Stephen Tyree
> Assignee: Stephen Tyree
> Priority: Minor
> Attachments: ZOOKEEPER-1051.patch
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> In libzookeeper_mt, if your process is going rather slowly (such as when running it in Valgrind's Memcheck) or you are using gdb with breakpoints, you can occasionally get SIGPIPE when trying to send a message to the cluster. For example:
> ==12788==
> ==12788== Process terminating with default action of signal 13 (SIGPIPE)
> ==12788== at 0x3F5180DE91: send (in /lib64/libpthread-2.5.so)
> ==12788== by 0x7F060AA: ??? (in /usr/lib64/libzookeeper_mt.so.2.0.0)
> ==12788== by 0x7F06E5B: zookeeper_process (in /usr/lib64/libzookeeper_mt.so.2.0.0)
> ==12788== by 0x7F0D38E: ??? (in /usr/lib64/libzookeeper_mt.so.2.0.0)
> ==12788== by 0x3F5180673C: start_thread (in /lib64/libpthread-2.5.so)
> ==12788== by 0x3F50CD3F6C: clone (in /lib64/libc-2.5.so)
> ==12788==
> This is probably not the behavior we would like, since we handle server disconnections after a failed call to send. To fix this, there are a few options we could use. For BSD environments, we can tell a socket to never send SIGPIPE with send using setsockopt:
> setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, (void *)&set, sizeof(int));
> For Linux environments, we can add a MSG_NOSIGNAL flag to every send call that says to not send SIGPIPE on a bad file descriptor.
> For more information, see: http://stackoverflow.com/questions/108183/how-to-prevent-sigpipes-or-handle-them-properly
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira