Thanks Jacques. I think I have solved my immediate problem. I added
-Djava.io.tmpdir=/newtmp to the DRILL_JAVA_OPTS variable in drill-env.sh. I
am now able to start drillbit without error.

Scott

On Fri, Jul 29, 2016 at 4:29 PM, Jacques Nadeau <[email protected]> wrote:

> Unfortunately, the issue is underlying libraries tendancy to extract native
> libraries into tmp. For most individual libraries, there are system
> properties you can set to change but there is no global option. I'm
> guessing that you might have one more after this one: Snappy. For Snappy,
> the info for changing the extraction location is here:
>
>
> https://github.com/xerial/snappy-java/blob/master/src/main/java/org/xerial/snappy/SnappyLoader.java
>
> Hopefully, someone from MapR can answer the question for the MapR library.
>
>
>
> --
> Jacques Nadeau
> CTO and Co-Founder, Dremio
>
> On Wed, Jul 27, 2016 at 8:22 AM, scott <[email protected]> wrote:
>
> > Looks like that stopped the epoll error, but got stuck on another library
> > error. Is there some way to tell Drill not to use /tmp entirely?
> >
> > java.lang.reflect.InvocationTargetException
> >
> > Caused by: java.lang.UnsatisfiedLinkError: /tmp/
> > mapr-mapr-libMapRClient.5.1.0.37817-mapr.so: /tmp/
> > mapr-mapr-libMapRClient.5.1.0.37817-mapr.so: failed to map segment from
> > shared object: Operation not permitted
> >
> >
> >
> > Thanks,
> > Scott
> >
> > On Wed, Jul 27, 2016 at 2:06 PM, scott <[email protected]> wrote:
> >
> > > Thanks Jacques. I'll give this a try.
> > >
> > > Scott
> > >
> > > On Wed, Jul 27, 2016 at 1:54 AM, Jacques Nadeau <[email protected]>
> > > wrote:
> > >
> > >> I don't think this will fix your issue since this is a internal
> > >> extraction.
> > >> Try using: -Ddrill.exec.enable-epoll=false in your drill-env. That
> > should
> > >> (hopefully) disable the extraction of epoll drivers (which should
> > actually
> > >> be disabled by default I believe due to disconnection problems in
> heavy
> > >> load cases).
> > >>
> > >>
> > >> --
> > >> Jacques Nadeau
> > >> CTO and Co-Founder, Dremio
> > >>
> > >> On Tue, Jul 26, 2016 at 7:20 AM, scott <[email protected]> wrote:
> > >>
> > >> > Thanks Leon for the suggestion, but do you think this config change
> > will
> > >> > help with my startup problem? It looks like it changes operations
> for
> > >> sort
> > >> > after startup.
> > >> >
> > >> > Scott
> > >> >
> > >> > On Mon, Jul 25, 2016 at 3:55 PM, Leon Clayton <
> [email protected]>
> > >> > wrote:
> > >> >
> > >> > >
> > >> > > I move the /tmp off local disk into the distributed FS on a node
> > local
> > >> > > volume on MapR. Other file systems can be inserted.
> > >> > >
> > >> > > Open up drill-override.conf on all of the nodes, and insert this :
> > >> > >
> > >> > > sort: {
> > >> > >     purge.threshold : 100,
> > >> > >     external: {
> > >> > >       batch.size : 4000,
> > >> > >       spill: {
> > >> > >         batch.size : 4000,
> > >> > >         group.size : 100,
> > >> > >         threshold : 200,
> > >> > >         directories : [ "/var/mapr/local/Hostname/drillspill" ],
> > >> > >         fs : "maprfs:///"
> > >> > >       }
> > >> > >     }
> > >> > >   }
> > >> > >
> > >> > > > On 25 Jul 2016, at 16:44, scott <[email protected]> wrote:
> > >> > > >
> > >> > > > Hello,
> > >> > > > I've run into an issue where Drill will not start if mount
> > >> permissions
> > >> > > are
> > >> > > > set on /tmp to noexec. The permissions were set to noexec due to
> > >> > security
> > >> > > > concerns. I'm using Drill version 1.7. The error I get when
> > starting
> > >> > > Drill
> > >> > > > is:
> > >> > > >
> > >> > > > Exception in thread "main" java.lang.UnsatisfiedLinkError:
> > >> > > > /tmp/libnetty-transport-native-epoll5743269078378802025.so:
> > >> > > > /tmp/libnetty-transport-native-epoll5743269078378802025.so:
> failed
> > >> to
> > >> > map
> > >> > > > segment from shared object: Operation not permitted
> > >> > > >
> > >> > > > Does anyone know of a way to configure Drill to use a different
> > tmp
> > >> > > > location?
> > >> > > >
> > >> > > > Thanks,
> > >> > > > Scott
> > >> > >
> > >> > >
> > >> >
> > >>
> > >
> > >
> >
>

Reply via email to