6

Upon trying to use a jar on the local linux machine, I am getting the following error: library initialization failed - unable to allocate file descriptor table - out of memory

The machine has 32G RAM

I can provide additional information, if needed.

Any help would be appreciated.

user680111
  • 971
  • 1
  • 9
  • 17
  • you can try increasing the JVM heap memory size using -Xmx flag when invoking jvm. please refer https://stackoverflow.com/a/14763095/3981536 – Jos Mar 22 '18 at 17:41
  • I've already tried doing this, unfortunately, it does not help. – user680111 Mar 22 '18 at 17:49
  • try inspecting the application using jVisualVM. you get a better understanding of how the memory is growing. also you can look at GC activity using a plugin called VisualGC, that will give good understanding of how various memory area in JVM is behaving – Jos Mar 22 '18 at 17:51
  • 1
    I just had the same error. You can try enabling memory overcommiting, by setting `/proc/sys/vm/overcommit_memory` to 1. That worked for me. – Dario Seidl Dec 28 '18 at 12:05

3 Answers3

8

In recent versions of Linux default limit for the number of open files has been increased significantly. Java 8 does the wrong thing of trying to allocate memory upfront for this number of file descriptors (see https://bugs.openjdk.java.net/browse/JDK-8150460). Previously this worked, when the default limit was much lower, but now it tries to allocate too much and fails. Workaround for this is to set a lower limit of number of open files (or use newer java):

$ mvn
library initialization failed - unable to allocate file descriptor table - out of memoryAborted
$ ulimit -n 10000
$ mvn
[INFO] Scanning for projects...
...
Alesya Huzik
  • 1,520
  • 14
  • 17
  • worked for me, struggled with that for hours.... simply do smth like `echo "ulimit -n 10000 >> /root/.bashrc"` – thi gg Oct 15 '19 at 09:46
1

Had this happen to me on some Java applications and curiously all electron-based apps (such as Spotify) after upgrading my Manjaro Linux about a week ago (today is November 19, 2019).

What fixed it was this command (as root, sudo didn't do it:

echo >/etc/security/limits.d/systemd.conf "* hard nofile 1048576"

Then reboot

Hope this helps someone.

Jeronimo Backes
  • 6,141
  • 2
  • 25
  • 29
1

None of the other fixes I found online worked for me, however I noticed that the bug responsible for this defect is in Java 9, and has been resolved since.

I'm on ArchLinux so I notice that when I tried to start the elasticsearch.service in journalctl -xe it showed that for some reason JRE8 was running it, and indeed archlinux-java status showed that Java 8 was the default. Setting to Java 11 fixed the problem for me:

 # archlinux-java set java-11-openjdk
DBedrenko
  • 4,871
  • 4
  • 38
  • 73