[
https://issues.apache.org/jira/browse/HDFS-4831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13659990#comment-13659990
]
Colin Patrick McCabe commented on HDFS-4831:
--------------------------------------------
It's interesting that this is coming up only for {{libhdfs}} users. My guess
is that when you launch a standalone JVM, it sets up a signal handler that
ignores {{SIGPIPE}}, but JNI code does not get this same benefit.
One way to fix this is modify your program which uses {{libhdfs}} to call this
prior to initializing {{JNI}}:
{code}
signal(SIGPIPE, SIG_IGN);
{code}
This ignores the {{SIGPIPE}} signal whenever it happens. When you initialize
JNI, it creates its own signal handlers, which will call the previously
installed signal handler if it was explicitly set (i.e., is not the default).
However, this is kind of a hack. We shouldn't expect {{libhdfs}} users to have
to jump through these kind of hoops. The best fix is to use {{MSG_NOSIGNAL}}
or {{MSG_NOSIGPIPE}} to avoid generating these signals in the first place.
> Performing direct read using libhdfs sometimes raises SIGPIPE (which in turn
> throws SIGABRT) causing client crashes
> -------------------------------------------------------------------------------------------------------------------
>
> Key: HDFS-4831
> URL: https://issues.apache.org/jira/browse/HDFS-4831
> Project: Hadoop HDFS
> Issue Type: Bug
> Components: libhdfs
> Affects Versions: 2.0.4-alpha
> Reporter: Lenni Kuff
>
> Reading using libhdfs sometimes raises SIGPIPE (which in turn throws SIGABRT
> from JVM_handle_linux_signal). This can lead to crashes in the client
> application. It would be nice if libhdfs handled this signal internally.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
