JRuby fails to load FFI support with obscure error when /tmp is not writable #1302
Comments
|
I just ran into this issue, can this error message be made better somehow? |
|
Much better would be a fix for the problem - how can I get around this issue if making |
|
@jkraemer you can set |
|
Anyone aware of this? datastax.driver.core.Native:113 -Could not load JNR C Library, native system calls through this library will not be available |
|
Just ran into this, (CentOS 7 some distros have /tmp non-writable by default :( ). For google followers, the error messages now look like this: and suggestion/feature request: if /tmp not executable, fallback to ~/.jruby-cache or something. Cheers!.. |
|
Hmm I suppose we could fall back, but I don't like the thought that we'd now dumping binaries into an even more unexpected location. The error should definitely be clearer though. How can a system work with a read-only /tmp? Are we not paying attention to some user TMP variable or something? |
|
hmm maybe /run/whatever or something like that?
…On Wed, Sep 11, 2019 at 2:38 PM Charles Oliver Nutter < ***@***.***> wrote:
Hmm I suppose we could fall back, but I don't like the thought that we'd
now dumping binaries into an even more unexpected location. The error
should definitely be clearer though.
How can a system work with a read-only /tmp? Are we not paying attention
to some user TMP variable or something?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#1302?email_source=notifications&email_token=AAADBUDRFGUWA6MPQPDEEPTQJFJM3A5CNFSM4AKHADB2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6P2GVI#issuecomment-530555733>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAADBUESZR2JNRSJVVZDIKLQJFJM3ANCNFSM4AKHADBQ>
.
|
|
@rdp I think the issue you have there is that it's actually disallowing executables from /tmp, which is a feature of some "secure" Linux distributions. I believe if you set your own TMP or TEMP or whatever, it will work. Can you confirm? |
In jruby/jruby#1302 we see that attempting to load FFI type defs when the jffi stub can't be loaded results in IllegalStateException being raised when we try to initCause on an UnsatisfiedLinkError. It appears that (sometimes?) simply constructing this exception initializes its cause, which can only be done once. Our attempt to initialize it again triggers the error. Since ULE does not have a constructor that accepts a cause, the only option here is to include the message from the triggering exception.
|
The original weirdness of this error was due to JFFI attempting to Note that you will still have to set the appropriate property or flag for verbose native loading in order to see the updated error, but it now explains that we need a writable, exec-able temp location. |
|
Also FWIW, JRuby should be attempting to fall back on the current directory for this temporary library, which isn't great but it's the behavior we have in place. |
|
Sweet. With 9.2.8.0 it was failing but with 9.2.9.0-SNAPSHOT seems to be working great, even if the CWD isn't executable, sweet! |
|
For me (using the jruby-complete-jar) setting TEMPDIR et al. doesn't seem to work. It works "just fine" when running jruby-9.2.17.0/bin/jruby (the executable), but not when using the jar, then it needs |
|
@rdp Based on this SO post, it seems like the default temp dir on non-Windows is always https://stackoverflow.com/questions/1924136/environment-variable-to-control-java-io-tmpdir I have not confirmed this myself, but it is a bit of a surprise; I was under the impression that As it stands, it would be inappropriate for us to change the value of |
|
I updated the wiki page, at least it'll give more clues for followers now :)
On Thursday, May 13, 2021, Charles Oliver Nutter ***@***.***> wrote:
@rdp Based on this SO post, it seems like the default temp dir on
non-Windows is always /tmp unless specified via the property, and no env
vars are looked at. Windows, however, will look at TMP and possibly other
places (registry?).
I have not confirmed this myself, but it is a bit of a surprise; I was
under the impression that java.io.tmpdir would default to whatever the
environment's TEMP env or similar are set to.
As it stands, it would be inappropriate for us to change the value of
java.io.tmpdir from JRuby or jffi, so the only option to me would be for
JRuby to use "proper" enviroment-variable logic to give jffi a location (or
we just document that it will use the java.io.tmpdir location or whatever
location you set via jffi's jffi.extract.dir and jffi.extract.name
properties and leave it at that).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.<
|
@rdp Thanks! Let me know if you think there's more we can do to make this clear (or if you come up with an idea for making it honor temp locations without diverging too much from |
qerub commentedDec 4, 2013
I noticed this when I accidentally changed permissions for
/tmp. A more informative message would be helpful. :)The text was updated successfully, but these errors were encountered: