Is it safe to ignore?

Yes. A Paper maintainer answered the original report with "You should be able to ignore it," and the code backs that up. The message is printed from a static initialiser when the class is first loaded, not from anything the server actually asked for, and the function it failed to find is only used by the code path that allocates a brand new pseudo terminal. A Minecraft server console attaches to the terminal it was started with instead, which uses different functions that resolved fine.

Why does Java 21 not print it?

Because JLine picks a different terminal backend there. The Foreign Function and Memory API was only finalised in Java 22, so on Java 21 JLine uses its JNI backend, whose native library compiles openpty in directly and never has to look it up at runtime. Java 25 uses the FFM backend, which resolves the symbol itself, and that lookup is what fails.

Why does Windows not print it?

openpty is a POSIX function and the class that emits the warning is JLine's binding to the POSIX C library. Windows uses a separate terminal implementation that never loads it.

Which Linux systems are affected?

Older ones, which is the opposite of what the first diagnosis suggested. On glibc 2.34 and newer, so Ubuntu 22.04 and up, Debian 12 and up, RHEL 9, Fedora 35 and up, openpty lives in libc.so.6 and the very first lookup finds it with no warning at all. The reporter could only reproduce it on Ubuntu 18, where openpty is still in a separate libutil that exists on disk only under its versioned name in a directory JLine did not search.

Does updating my server jar fix it?

Not as of 6 August 2026. Paper still declares jline-terminal-ffm 3.27.1, which predates the fix, and the open pull request to bump that dependency targets JLine 4.3.1, which was published before the fix was merged. The reporter tested a jar built from that pull request and the warning was still there.

Can I silence it without waiting?

On an affected system, yes, by giving the loader the unversioned filename it is looking for. Symlink libutil.so.1 to libutil.so in a directory of your own, then start the server with -Djava.library.path pointing at that directory. A system wide symlink next to the real library works too. Neither is necessary, since nothing is broken.

Guidefor server owners3 min read

The openpty warning on Java 25: harmless, and here is the proof

Java 25 servers on some Linux systems print an UnsatisfiedLinkError about openpty and libutil before the server even starts. What causes it, why it is cosmetic, which JLine version fixes it, and why a newer server jar does not carry that fix yet.

What you are seeing

Before the server logs a single line of its own, the console prints this:

Starting org.bukkit.craftbukkit.Main
Juli 09, 2026 2:01:27 PM org.jline.terminal.impl.ffm.CLibrary <clinit>
WARNUNG: Unable to find openpty native method in static libraries and unable to load the util library.
        - java.lang.UnsatisfiedLinkError: no util in java.library.path: /usr/java/packages/lib:/usr/lib64:/lib64:/lib:/usr/lib
[14:01:27 INFO]: [bootstrap] Running Java 25 ...

WARNUNG is just the German locale of WARNING. The reporter who opened the Paper issue noticed two things that are worth repeating: it appears on Linux and not on Windows, and it did not appear on the same box under Minecraft 1.21.11 with Java 21. It also never reaches logs/latest.log, because JLine logs through the JVM's own logging rather than through the server's Log4j appenders.

The short answer

It is cosmetic. A Paper maintainer replied to the report with "You should be able to ignore it," and the JLine source confirms why.

The message comes from a static initialiser in org.jline.terminal.impl.ffm.CLibrary, which is why it prints before the server does anything. That class resolves a handful of C functions when it is first loaded. tcgetattr, ttyname_r and the rest resolve fine. Only openpty fails, and the class records the failure rather than throwing.

The handle it failed to build is used by exactly one method, the one that allocates a new pseudo terminal from scratch. A server console does not do that. It attaches to the terminal it was launched with, through a separate system stream path that uses the functions that did resolve. So the failed lookup is reported at load time and then never consulted.

What actually triggers it

The first published diagnosis was that glibc 2.34 folded openpty into libc.so.6, so the standalone libutil.so stopped existing and JLine, which only knew to look in libutil, came up empty. That half is true about glibc, and it is the wrong explanation for this warning. The JLine maintainer corrected it in the same thread.

On glibc 2.34 and newer, the JVM's default symbol lookup already searches every globally loaded object, libc.so.6 is always one of them, and openpty is found on the first attempt. Those are the systems where nothing is printed at all. The reporter confirmed this by testing: Ubuntu 20 and Ubuntu 22 were clean, Ubuntu 18 was not.

The failure is at the other end. On Ubuntu 18 the function is still in a separate library, and that library is present, as /lib/x86_64-linux-gnu/libutil.so.1. JLine's fallbacks were System.loadLibrary("util"), which wants an unversioned libutil.so that a runtime-only package never installs, and a scan of /usr/lib/<arch>-linux-gnu/, which is the wrong directory on a system that predates the usr merge. So the file was sitting right there and nothing looked for it.

Which JLine version fixes it

Two changes, both merged in July 2026. The first adds an explicit lookup in libc.so.6, which is the belt-and-braces fix for glibc 2.34 and newer where the default lookup already worked. The second is the one that matters here: it widens the versioned libutil.so.* search to /lib/<arch>-linux-gnu, /usr/lib64 and /lib64 as well.

Both landed in jline-terminal-ffm 3.30.16, published on 21 July 2026. You can confirm it in the jar: the 3.30.16 class contains the strings libc.so.6, /usr/lib64 and /lib64, and the 3.27.1 class does not. On the 4.x line the fix is only in the unreleased 4.3.2, since 4.3.1 was published on 30 June, before either change was merged.

Whether a newer server jar carries it

Not yet. Paper's build declares jline-terminal-ffm:3.27.1, and the open pull request to bump it targets 4.3.1, which predates the fix on that branch. The reporter built that pull request and the warning was unchanged. Until a build ships 3.30.16 or 4.3.2, updating your server jar will not remove the line.

That is fine, because there is nothing to remove except the line itself. If you want it gone today, symlink the versioned library under the plain libutil.so name into a directory of your own and add -Djava.library.path= for it to your start command. If you would rather not touch the system, leave it. Your server is not missing anything.

One thing the same thread contains, and the same thing this warning is not: a separate console error on shutdown, which a Paper maintainer attributed to the long-standing ordering problem between the logging system shutting down and the terminal still being written to. Different problem, same log file.

Last reviewed 2026-08-06. Version data on this site updates automatically; this guide is reviewed by hand when the ecosystem changes.