Open Paxa opened 7 years ago
There must be something equivalent? I'm hoping we just need to try a different symbol name and hopefully detect that we're on musl vs glibc or similar...
Ahh, I see what's happening here. The _r
versions of these netdb functions are provided by GNU libc as reentrant versions of the regular names (according to the header on my glibc-based Fedora machine).
I was able to find man pages for getprotobyname_r
on Arch, so this isn't specifically an Arch problem...unless they've recently started defaulting to musl libc.
A search for musl getprotobyname_r brings up many bug reports of C libraries and applications failing to build against musl, so this is a fairly widespread problem.
So there's two solutions I can see here.
There may also be a recommended alternative to these non-reentrant versions on musl. I have not done that research yet.
Hmm, here's the weird thing...jnr-netdb currently does do a call to getProtoByName and getProtoByNumber during the library initialization, presumably for this precise reason. So perhaps the version you tested did not have an updated jnr-netdb? I'm getting Arch set up so I can try it here.
Ok, finally managed to get an Arch VM set up and I can confirm jnr-netdb is a little messed up there. A bunch of tests fail. They may all be the same root cause, but the errors did not all seem related. Any help you can provide here would be a big help. Check out jnr-netdb, have maven and a Java 8 JDK installed, and run "mvn install". You'll see the errors.
Ok, so here's what I've learned.
getservicebyname_r
does not appear to return the aliases, even though they're both in /etc/services
._r
versions of these APIs.So again the issue is not Arch (for purposes of this bug). I'll dig around and see if there's a workaround for the missing _r
functions on musl.
Actually it print stacktrace but still worked, I had bug in application. Currently use docker image with glibc and it works great ( https://hub.docker.com/r/anapsix/alpine-java/ )
Oh! So it doesn't fail completely but logs that exception? That may simply be a missed printStackTrace
in the failover logic. I'll check on that.
Incidentally, if you can try to mvn test
jnr-netdb on your system and report the results, I'd appreciate it. You should have four failures in some of the "services" tests due to the alias difference I mention above.
Ok, so all I could see logging that exception is a log message at level "warning". Could you or your app be setting the JVM's log level to warning or lower?
Alpine linux don't have
getprotobyname_r
Related https://github.com/jruby/jruby/issues/4408