On Wed, Aug 21, 2013 at 3:49 PM, Stack <st...@duboce.net> wrote: > On Wed, Aug 21, 2013 at 1:25 PM, Colin McCabe <cmcc...@alumni.cmu.edu>wrote: > >> St.Ack wrote: >> >> > + Once I figured where the logs were, found that JAVA_HOME was not being >> > exported (don't need this in hadoop-2.0.5 for instance). Adding an >> > exported JAVA_HOME to my running shell which don't seem right but it took >> > care of it (I gave up pretty quick on messing w/ >> > yarn.nodemanager.env-whitelist and yarn.nodemanager.admin-env -- I wasn't >> > getting anywhere) >> >> I thought that we were always supposed to have JAVA_HOME set when >> running any of these commands. At least, I do. How else can the >> system disambiguate between different Java installs? I need 2 >> installs to test with JDK7. >> >> > > That is fair enough but I did not need to define this explicitly previously > (for hadoop-2.0.5-alpha for instance) or the JAVA_HOME that was figured in > start scripts was propagated and now is not (I have not dug in). > > > >> > + This did not seem to work for me: >> > <name>hadoop.security.group.mapping</name> >> > >> <value>org.apache.hadoop.security.JniBasedUnixGroupsMappingWithFallback</va >> > lue>. >> >> We've seen this before. I think your problem is that you have >> java.library.path set correctly (what System.loadLibrary checks), but >> your system library path does not include a necessary dependency of >> libhadoop.so-- most likely, libjvm.so. Probably, we should fix >> NativeCodeLoader to actually make a function call in libhadoop.so >> before it declares everything OK. >> > > My expectation was that if native group lookup fails, as it does here, then > the 'Fallback' would kick in and we'd do the Shell query. This mechanism > does not seem to be working.
I filed https://issues.apache.org/jira/browse/HADOOP-9895 to address this issue. best, Colin > > > St.Ack
