I swear this came up in IRC not too long ago, but I don't recall what the outcome was. I think it had something to do with the library load path being messed up somehow. This should be implemented in FreeBSD:

https://github.com/jnr/jnr-posix/blob/1be3a8871c076e0707ada78392814ef6ebe1d768/src/main/java/jnr/posix/FreeBSDFileStat.java#L92-L94

But it looks like that's not being used.

Have you disabled native library support by chance?

Hi @nirvdrum, thank you very much for your answer.

No, the environment under which the application is started should be clean, so native library support should get its default value. I tried setting the jruby.native.enabled property but the error is the same no matter if it is true or false.

However, it seems clear from your source pointer that it should be implemented in FreeBSD so that I tried replicating the same setup in the previous FreeBSD release (9.2) and there, it works.

I tried searching JRuby's IRC channel logs here but the Search link there seems to be broken. However, I'll investigate about the library load path.

Cheers,
-- Enrico

It may be related to these jnr-ffi issues:

jnr/jnr-ffi#16
jnr/jnr-ffi#17
jnr/jnr-ffi#18

Thank you very much, @nirvdrum, they look like they could be the cause of the problem.

Cheers,
-- Enrico

Hi all,

I've sent PR 26 to jnr-ffi to fix this issue, that is the same patch suggested in PR 18 and PR 21 (for which the Travis CI build was failing, and I guess that was the reason for them to be ignored).

I'm leaving this comment for reference because It seems that no PR in the jnr-ffi repository has been replied to in quite some time, and I guess affected users may end up here as well.

Hi all,

Here's a follow-up on this issue.

jnr-ffi upstream has been silent so far, so that I had to fork that project in order to be provide a temporary fix to FreeBSD's logstash port. Until jnr-ffi is broken on FreeBSD I'll try to maintain my fork alive and to track upstream. If anybody hits this bug on other platforms (besides FreeBSD I've seen reports of Solaris being affected), you can build jnr-ffi from my fork and use it as a drop-in replacement.

The best solution, however, would be upstream fixing the problem. It is ironic to choose to use Java programs and libraries only to discover that they fail on your platform because they have incompatible native bindings.

Since JRuby is using jnr-ffi and the bug sometimes deceives user into believing it's a JRuby bug, would it be possible for you to kindly lobby jnr-ffi to at least take the PR into consideration? After all, this may be JRuby's collateral damage.

Thanks,

Enrico.

Hi all,

the PR fixing this issue has been merged into jnr-ffi upstream.

thanx for the follow up

let's keep it open until we get jnr-ffi released and used by jruby

Hi,

I'm seeing pretty much exactly this error on SunOS 5.8 on sparc using Logstash 1.4.3.
With:
java version "1.6.0_41"
Java(TM) SE Runtime Environment (build 1.6.0_41-b02)
Java HotSpot(TM) Server VM (build 20.14-b01, mixed mode)

The full error is below. Could anyone shed any light on this error and how to resolve it? I arrived here as the error appears to be a very close match.

Thanks
Stuart

// ERROR MESSAGE//
NotImplementedError: stat.st_dev unsupported or native support failed to load
dev_major at org/jruby/RubyFileStat.java:190
_discover_file at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/filewatch/watch.rb:150
each at org/jruby/RubyArray.java:1613
_discover_file at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/filewatch/watch.rb:132
watch at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/filewatch/watch.rb:38
tail at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/filewatch/tail.rb:67
run at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/logstash/inputs/file.rb:130
each at org/jruby/RubyArray.java:1613
run at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/logstash/inputs/file.rb:130
inputworker at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/logstash/pipeline.rb:163
start_input at /home/sitescope/logstash/logstash-1.4.3.dev-modified/lib/logstash/pipeline.rb:157
+---------------------------------------------------------+
| An unexpected error occurred. This is probably a bug. |
| You can find help with this problem in a few places: |
| |
| * chat: #logstash IRC channel on freenode irc. |
| IRC via the web: http://goo.gl/TI4Ro |
| * email: logstash-users@googlegroups.com |
| * bug system: https://logstash.jira.com/ |
| |
+---------------------------------------------------------+
The error reported is:
Bad file number - Bad file descriptor

Hi @kryten68, if you are curious, have a look at jnr/jnr-ffi#26: at least on FreeBSD jnr-ffi is choking on an ld script (beginning with a comment) and it incorrectly reports it as a broken binary.

Patching jnr-ffi is easy (it's just a regular expression to fix) but then you have to substitute the recompiled Java class into the JRuby JAR bundled with Logstash.

Chances are the same thing is happening on Solaris: check the library that it's trying to open and see if it's an ld script.

The FreeBSD port Makefile has the code to patch the Logstash distribution: you can use that code and, until JRuby bundles the patched jnr-ffi and until this new JRuby version ends into Logstash, you can use my jnr-ffi fork.

closing since jnr/jnr-ffi#26 is part of jnr-ffi-2.0.2

@kryten68 could file an issue for solaris - can not help due to lack of access to Solaris - maybe you can prepare a PR which is definitely welcome ;)

Having the precisely same problem on Solaris 5.9 with logstash-1.4.2.

Logstash is doing stat = File::Stat.new(file) and needs the inode number returned. Is there any different call that can be used to get the inode number?