Ah, ok we’ve been using -Pr, that explains the issue. I’ll switch to -Psparkr for now.
We start the zeppelin process from the users home directory, basically: cd; /usr/share/zeppelin/bin/zeppelin-daemon.sh start The main reason we’re not using docker (would love to do that) is that we have to use kerberos, there’s a lot of shared setup with the host that is difficult to replicate in docker. /Johan On 4/8/16, 10:36 AM, "Jeff Steinmetz" <jeffrey.steinm...@gmail.com> wrote: >Here are a few hints regarding the R interpreters: > >Did you build with `-Pr` or `-Psparkr` (there are 2 spark interpreters on the >latest master branch)? > >Using the R interpreter available via the `-Psparkr` build profile on the >latest snapshot (Master branch) should work without setting any zeppelin or >spark home directories, if you start spark from the home directory with >something like > >chdir /usr/share/zeppelin >exec bin/zeppelin-daemon.sh start > > > >The `-Psparkr` profile is also set up to work with `-Pbuild-distr`. >If you are running the R interpreter built with `-Pr`, from the binary >distribution built with `-Pbuild-distr, that R interpreter build profile is >not code complete on the Master branch to work with the binary distribution >build profile yet - you can run it from the source root after your build >though. > >The nginx proxy is likely not the issue (we currently using -Psparkr behind >nginx just fine using the change directory approach above and in the following >service example) > >If you use an upstart script (such as running zeppelin as a service on >Ubuntu), you can change the directory to the zeppelin home directory before >running the zeppelin upstart option, which also works > >There is an example upstart script at the bottom of this help page that >demonstrates this: > > >https://zeppelin.incubator.apache.org/docs/0.6.0-incubating-SNAPSHOT/install/install.html > > > >Jeff Steinmetz > > > > >On 4/8/16, 8:02 AM, "MUEDSAM, JOHAN" <jm8...@att.com> wrote: > >>Our setup is that we reverse proxying Zeppelin behind nginx. We have a common >>install but each user has their own conf, logs, notebook, webapps and >>local-repo directory. Nginx fires up Zeppelin user-owned Zeppelin instances >>on-demand. The Zeppelin instance is started with the users home directory as >>current working directory to enable easy access to your own files and also >>the knitr figure directory. >> >>The problem we run into is that the rzeppelin package can’t be found. The >>rinterpeter code assumes the R/lib directory is in the current working >>directory or the parent directory as can be seen from the stack trace below. >>I’ve patched this to look for R/lib directory in ZEPPELIN_HOME so that all >>users can share the code. >> >>Is ZEPPELIN_HOME the best path to look for it or should the R/lib directory >>be moved into some other sub-directory under ZEPPELIN_HOME? If so I can >>update my patch and create a pull request. If not I’ll submit the patch as is. >> >> >>Caused by: java.lang.RuntimeException: Could not find rzeppelin - it must be >>in either R/lib or ../R/lib >> at >> org.apache.zeppelin.rinterpreter.RContext$.apply(RContext.scala:297) >> at >> org.apache.zeppelin.rinterpreter.RInterpreter.rContext$lzycompute(RInterpreter.scala:44) >> at >> org.apache.zeppelin.rinterpreter.RInterpreter.rContext(RInterpreter.scala:44) >> >> >> >> >>/Johan >> >> >
