JNA 4.4.0 requires glibc 2.14

[jasontedor]

Nothing is ever simple. In #23636, JNA was upgraded from version 4.2.2 to version 4.4.0. Unfortunately, JNA 4.4.0 is linked against glibc 2.14 which is not available on all platforms that we support (e.g., CentOS 6). JNA is not required for Elasticsearch to function, but it not being available means:

• we can not check if Elasticsearch is running as root
• we can not install seccomp
• we can not memory lock
• we can not perform all the bootstrap checks

The last point is technically not true; the first three are damning anyway. On stable platforms like CentOS 6, glibc 2.14 will never safely be available, and these OS will be around for awhile (we might not support them for their entire life, but we are not retiring them anytime soon). We do not want to be tied to JNA 4.2.2 forever, so this issue is a placeholder for finding a solution to this problem. One idea would be to ship both and set the classpath based on the version of glibc that is available.

[ywelsch]

A few more options:

• Create our own build of JNA 4.4.0 against an older version of glibc, see Support LTS distributions java-native-access/jna#771
• Not support/disable the functionality provided by JNA on CentOS6
• Stick with 4.2.2 in 5.x branch and not provide CentOS6 support for ES 6.0

[jasontedor]

I considered all three of those options, and I do not think that we should pursue them.

Create our own build of JNA 4.4.0 against an older version of glibc, see java-native-access/jna#771

I don't think that we should get into this business, it complicates our build and will not be as battle-tested as the actual JNA distributions.

Not support/disable the functionality provided by JNA on CentOS6

I think that this is a non-option for an OS that we support.

Stick with 4.2.2 in 5.x branch and not provide CentOS6 support for ES 6.0

I would love for this to be possible but I have my doubts about whether or not it is.

[jasontedor]

Create our own build of JNA 4.4.0 against an older version of glibc, see java-native-access/jna#771

We are going to proceed with this option after all. 😄