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]