[
https://issues.apache.org/jira/browse/HADOOP-7156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13004333#comment-13004333
]
Greg Roelofs commented on HADOOP-7156:
--------------------------------------
That wasn't my personal experience (with the setup-related ones), but
admittedly it's a tiny sample.
Dude, I'm still running a 2004-era distro on one of my desktop boxes!
Sure, that's unusual, but ancient servers in production definitely
aren't. The more you have, the harder it is to validate and move to
a new version. You've got, what, a few hundred servers to worry about?
We've got a few hundred thousand. (Not all Hadoop-related, I mean, just
in general.) I have no idea what the overall mix is, but I was aware of
both RHEL 5.x and 4.x subsets up until fairly recently (the latter also
being 2004-era; the former more like 2007, I think), and I wouldn't be
surprised if there were still *BSD boxes lurking somewhere. I don't
think there are any RHEL 6.x yet.
So no, OS-related docs don't get stale _that_ quickly, at least not for
some of us. :-)
Not at all. It's simply a statement that those working most closely with
the code and XML configs--i.e., those who _do_ watch JIRAs and the mailing
lists religiously--are more likely to keep things updated if they're
nearby/noticeable. We all have limited attention-hours to devote to
maintenance, so anything that makes it easier, faster, or more likely to
happen is a Good Thing.
And I _know_ you're aware that the default state for documentation is
"nonexistent." Especially where developers are concerned.
(Btw, wasn't there a recent suggestion to automatically pull config keys
and descriptions out of the foo-default.xml files and publish them? With
something like that in place, the docs you want would fall out of this
and similar patches immediately. One of my mottos for the last few years
has been, "if it can be automated, it should be automated.")
I guess this has drifted a bit; perhaps further discussion should go to
one of the lists?
> getpwuid_r is not thread-safe on RHEL6
> --------------------------------------
>
> Key: HADOOP-7156
> URL: https://issues.apache.org/jira/browse/HADOOP-7156
> Project: Hadoop Common
> Issue Type: Bug
> Affects Versions: 0.22.0
> Environment: RHEL 6.0 "Santiago"
> Reporter: Todd Lipcon
> Assignee: Todd Lipcon
> Priority: Critical
> Fix For: 0.22.0
>
> Attachments: hadoop-7156.txt, hadoop-7156.txt, hadoop-7156.txt
>
>
> Due to the following bug in SSSD, functions like getpwuid_r are not
> thread-safe in RHEL 6.0 if sssd is specified in /etc/nsswitch.conf (as it is
> by default):
> https://fedorahosted.org/sssd/ticket/640
> This causes many fetch failures in the case that the native libraries are
> available, since the SecureIO functions call getpwuid_r as part of fstat. By
> enabling -Xcheck:jni I get the following trace on JVM crash:
> *** glibc detected *** /mnt/toolchain/JDK6u20-64bit/bin/java: free(): invalid
> pointer: 0x0000003575741d23 ***
> ======= Backtrace: =========
> /lib64/libc.so.6[0x3575675676]
> /lib64/libnss_sss.so.2(_nss_sss_getpwuid_r+0x11b)[0x7fe716cb42cb]
> /lib64/libc.so.6(getpwuid_r+0xdd)[0x35756a5dfd]
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
