Re: [jruby-user] JRuby 1.7.17: getppid unsupported or native support failed to load
Thomas E Enebo <[email protected]> Tue, 30 Dec 2014 09:15:50 -0600
| Newsgroups | gmane.comp.lang.jruby.user |
|---|---|
| Message-ID | <CAL5zZVnhrCWFAjrB46tbnL4vgtBjzU8Rp2=g7ydBd1jZMEnMMg@mail.gmail.com> |
Thanks for recording what you went through. Hopefully if someone else hits this they will stumble across this thread. For further note, I am using an image of Ubuntu 14.04 and Java 1.7.0u72 and libcrypt is in the same location as yours and things are working ok. So I am guessing Ubuntu or Java tweaked things and fixed it in later releases. -Tom On Mon, Dec 29, 2014 at 11:53 PM, Michael Pitman <[email protected]> wrote: > In the end, we clobbered the default ubuntu setup, and exposed the > libraries as described below. Note - this is quite dangerous, and if things > go wrong it could result in a virtually unusable system. > > The issue is that java is looking for libraries in /lib64 and /usr/lib64, > but they are actually installed under /lib/x86_64-linux-gnu and > /usr/lib/x86_64-linux-gnu > > First make sure there's nothing in /lib64 other than ld-linux: > cd / > ls -Al lib64 > # Results in > # ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.15.so > > > Now, we need to use the linked location of ld-linux in the commands below, > because we're going to delete it, which will break pretty much everything > until we make the symbolic link from lib64 again > > rm /lib64/ld-linux-x86-64.so.2 > /lib/x86_64-linux-gnu/ld-2.15.so /bin/rmdir /lib64 > /lib/x86_64-linux-gnu/ld-2.15.so /bin/ln -sTf lib/x86_64-linux-gnu lib64 > /lib/x86_64-linux-gnu/ld-2.15.so /bin/ln -sTf lib/x86_64-linux-gnu > usr/lib64 > ldconfig > > > Then, all should be well again, and java will have access to all the > native libraries. > > > On 30 December 2014 at 09:51, Michael Pitman <[email protected]> > wrote: > >> Some further investigation and googling reveals this to be a problem with >> Java on Linux, rather than specifically a jruby issue. >> >> Java does not look at the configured library paths (configured in >> /etc/ld.so.conf.d, but rather only at the environment >> variable LD_LIBRARY_PATH or the Java property java.library.path. On that >> machine, adding the path /lib/x86_64-linux-gnu to either of those paths >> also solves the problem. We're going to proceed with one of these solutions >> in our production environments. >> >> Thanks for your help. >> >> Michael >> >> >> On 23 December 2014 at 02:03, Thomas E Enebo <[email protected]> wrote: >> >>> Ok. This second email makes me feel a little better about putting out a >>> 1.7.18 :) >>> >>> I have not been a sysadmin for >20 years (so you could call me really >>> rusty -- rusty enough to give you tetanus) but to solve these sorts of >>> issues I used to just add the path to /etc/ldconfig. I think you can also >>> set LD_LIBRARY_PATH to include this as well if you do not have root >>> access. I don't know if Ubuntu is not exposing this directory for a >>> particular reason or not but I would guess examiing what other things are >>> in that directory would help figure that out. I am really really hoping >>> something went wrong on your particular system and the path did not get >>> added to ldcofig. >>> >>> If someone can determine this configuration is common for Ubuntu (or >>> other linuxes) we will try and figure out something which does not require >>> manual intervention. >>> >>> -Tom >>> >>> >>> On Sun, Dec 21, 2014 at 5:37 PM, Michael Pitman < >>> [email protected]> wrote: >>> >>>> Hi Tom, >>>> >>>> So it's picking up the library as "libcrypt.so.1" if it's installed in >>>> /lib (as it is in Ubuntu 10.04), but not if it's installed >>>> under /lib/x86_64-linux-gnu (as it is in Ubuntu 12.04). >>>> >>>> I can get it to load if I do either: >>>> >>>> ln -s /lib/x86_64-linux-gnu/libcrypt-2.15.so /lib/libcrypt.so.1 >>>> or >>>> ln -s /lib/x86_64-linux-gnu/libcrypt-2.15.so >>>> /lib/x86_64-linux-gnu/libcrypt.so >>>> >>>> ie link from /lib to /lib/x86_64-linux-gnu/ as libcrypt.so.1 or create >>>> the link as simply libcrypt.so under /lib/x86_64-linux-gnu >>>> >>>> It feels to me like that's not going to be the root cause, but rather >>>> would indicate a mis-configuration of the machine somewhere. >>>> >>>> Is it possible to get jruby working with this configuration (eg by >>>> using fall-backs), or do we consider this a machine configuration problem, >>>> and fix it on our production servers? >>>> >>>> Thanks, >>>> >>>> Michael >>>> >>>> >>>> >>>> On 20 December 2014 at 11:36, Michael Pitman <[email protected] >>>> > wrote: >>>> >>>>> Hi Tom, >>>>> >>>>> Thanks for that, it certainly detected the underlying problem: >>>>> >>>>> > jruby -Xnative.verbose=true -e 'p Process.ppid' >>>>> >>>>> Failed to load native POSIX impl; falling back on Java impl. >>>>> Stacktrace follows. >>>>> java.lang.UnsatisfiedLinkError: libcrypt.so: cannot open shared object >>>>> file: No such file or directory >>>>> at >>>>> jnr.ffi.provider.jffi.NativeLibrary.loadNativeLibraries(NativeLibrary.java:87) >>>>> at >>>>> jnr.ffi.provider.jffi.NativeLibrary.getNativeLibraries(NativeLibrary.java:70) >>>>> at >>>>> jnr.ffi.provider.jffi.NativeLibrary.getSymbolAddress(NativeLibrary.java:49) >>>>> at >>>>> jnr.ffi.provider.jffi.NativeLibrary.findSymbolAddress(NativeLibrary.java:59) >>>>> at >>>>> jnr.ffi.provider.jffi.AsmLibraryLoader.generateInterfaceImpl(AsmLibraryLoader.java:117) >>>>> at >>>>> jnr.ffi.provider.jffi.AsmLibraryLoader.loadLibrary(AsmLibraryLoader.java:59) >>>>> at >>>>> jnr.ffi.provider.jffi.NativeLibraryLoader.loadLibrary(NativeLibraryLoader.java:43) >>>>> at jnr.ffi.LibraryLoader.load(LibraryLoader.java:265) >>>>> at jnr.ffi.Library.loadLibrary(Library.java:123) >>>>> at >>>>> jnr.posix.POSIXFactory$DefaultLibCProvider$SingletonHolder.<clinit>(POSIXFactory.java:223) >>>>> at >>>>> jnr.posix.POSIXFactory$DefaultLibCProvider.getLibC(POSIXFactory.java:227) >>>>> at jnr.posix.BaseNativePOSIX.<init>(BaseNativePOSIX.java:36) >>>>> at jnr.posix.LinuxPOSIX.<init>(LinuxPOSIX.java:18) >>>>> at jnr.posix.POSIXFactory.loadLinuxPOSIX(POSIXFactory.java:95) >>>>> at jnr.posix.POSIXFactory.loadNativePOSIX(POSIXFactory.java:69) >>>>> at jnr.posix.POSIXFactory.loadPOSIX(POSIXFactory.java:38) >>>>> at jnr.posix.LazyPOSIX.loadPOSIX(LazyPOSIX.java:35) >>>>> at jnr.posix.LazyPOSIX.posix(LazyPOSIX.java:31) >>>>> at jnr.posix.LazyPOSIX.umask(LazyPOSIX.java:301) >>>>> at org.jruby.RubyFile.getUmaskSafe(RubyFile.java:1514) >>>>> ... >>>>> NotImplementedError: getppid unsupported or native support failed to >>>>> load >>>>> >>>>> >>>>> The machine has libcrypt installed: >>>>> >>>>> > ldconfig -p | grep libcrypt >>>>> libcrypto.so.1.0.0 (libc6,x86-64) => >>>>> /lib/x86_64-linux-gnu/libcrypto.so.1.0.0 >>>>> libcrypto.so.0.9.8 (libc6,x86-64) => >>>>> /lib/x86_64-linux-gnu/libcrypto.so.0.9.8 >>>>> libcrypto.so.0.9.8 (libc6,x86-64) => >>>>> /usr/lib/x86_64-linux-gnu/libcrypto.so.0.9.8 >>>>> libcrypt.so.1 (libc6,x86-64, OS ABI: Linux 2.6.24) => >>>>> /lib/x86_64-linux-gnu/libcrypt.so.1 >>>>> >>>>> >>>>> But it's not installed as libcrypt.so, since the package libc6 is >>>>> installed, but not libc6-dev, which installs and links that file. It also >>>>> explains why this is working on our dev machines, but not on the >>>>> production-like boxes. >>>>> >>>>> I'd rather not ask our clients to install development libraries on >>>>> their production machines, so is it possible to coerce jruby to use the >>>>> library installed as .so.1 if it is found? >>>>> >>>>> Thanks, >>>>> >>>>> Michael >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 20 December 2014 at 01:36, Thomas E Enebo <[email protected]> >>>>> wrote: >>>>>> >>>>>> Can you try jruby -Xnative.verbose=true -e 'p Process.ppid'? Can you >>>>>> also tell me whether this machine has libcrypt? That was the main change >>>>>> to jnr-posix around 1.7.17's release. >>>>>> >>>>>> -Tom >>>>>> >>>>>> On Thu, Dec 18, 2014 at 3:37 PM, Michael Pitman < >>>>>> [email protected]> wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm getting an error trying to run a "runnable" war on one of our >>>>>>> production (Ubuntu 12.04) machines under jruby 1.7.17. We have isolated it >>>>>>> just to 1.7.17, since it works OK when using 1.7.16.2, and all other gems >>>>>>> and code are identical. >>>>>>> >>>>>>> There must be something on that machining that's triggering this to >>>>>>> happen, since the exact same war file works on other machines. The machine >>>>>>> was failing while running java version 1.7.0_21, but I upgraded java >>>>>>> to 1.7.0_72 and it continues to fail. >>>>>>> >>>>>>> Anyway, below is the stack trace, and I'd appreciate any help in >>>>>>> resolving the issue. Below that I've listed the linked library versions, if >>>>>>> that's any help. >>>>>>> >>>>>>> Thanks very much, >>>>>>> >>>>>>> Michael >>>>>>> >>>>>>> NotImplementedError: getppid unsupported or native support failed to >>>>>>> load >>>>>>> org/jruby/RubyProcess.java:752:in `ppid' >>>>>>> org/jruby/RubyProcess.java:749:in `ppid' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/systemu-2.6.4/lib/systemu.rb:28:in >>>>>>> `SystemUniversal' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/systemu-2.6.4/lib/systemu.rb:13:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/macaddr-1.7.1/lib/macaddr.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/macaddr-1.7.1/lib/macaddr.rb:23:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/uuid-2.3.7/lib/uuid.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/uuid-2.3.7/lib/uuid.rb:14:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/header.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/header.rb:3:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:236:in >>>>>>> `load_dependency' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/activesupport-3.2.21/lib/active_support/dependencies.rb:251:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/builder.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/builder.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyArray.java:1613:in `each' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/operation.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyArray.java:1613:in `each' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/operation.rb:4:in >>>>>>> `(root)' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/client.rb:1:in >>>>>>> `(root)' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon/client.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1071:in `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon.rb:1:in >>>>>>> `(root)' >>>>>>> org/jruby/RubyKernel.java:1087:in `load' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/savon-2.8.0/lib/savon.rb:26:in >>>>>>> `(root)' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/bundler-1.7.8/lib/bundler/runtime.rb:1:in >>>>>>> `(root)' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/bundler-1.7.8/lib/bundler/runtime.rb:76:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/bundler-1.7.8/lib/bundler/runtime.rb:72:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/bundler-1.7.8/lib/bundler/runtime.rb:61:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/bundler-1.7.8/lib/bundler.rb:134:in >>>>>>> `require' >>>>>>> /tmp/jruby8149531281028435272extract/config/application.rb:13:in >>>>>>> `(root)' >>>>>>> /tmp/jruby8149531281028435272extract/Rakefile:1:in `(root)' >>>>>>> /tmp/jruby8149531281028435272extract/gems/gems/rake-10.4.2/bin/rake:36:in >>>>>>> `(root)' >>>>>>> error: org.jruby.exceptions.RaiseException: (SystemExit) exit >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> > ldd `which java` >>>>>>> linux-vdso.so.1 => (0x00007fffa53fe000) >>>>>>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 >>>>>>> (0x00007fb13ca13000) >>>>>>> libjli.so => not found >>>>>>> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fb13c80e000) >>>>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fb13c44f000) >>>>>>> /lib64/ld-linux-x86-64.so.2 (0x00007fb13cc36000) >>>>>>> >>>>>>> /lib/x86_64-linux-gnu/libpthread.so.0 -> libpthread-2.15.so >>>>>>> /lib/x86_64-linux-gnu/libdl.so.2 -> libdl-2.15.so >>>>>>> /lib/x86_64-linux-gnu/libc.so.6 -> libc-2.15.so >>>>>>> /lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.15.so >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> blog: http://blog.enebo.com twitter: tom_enebo >>>>>> mail: [email protected] >>>>>> >>>>> >>>> >>> >>> >>> -- >>> blog: http://blog.enebo.com twitter: tom_enebo >>> mail: [email protected] >>> >> >> > -- blog: http://blog.enebo.com twitter: tom_enebo mail: [email protected]