Pues parece que ya podemos añadir otra historia más a los problemas de systemd. Ahora resulta que un cambio inocente en sus políticas ha hecho que un bug serio en Java salga a la superficie: prácticamente todas las aplicaciones Java fallan en Debian SID por culpa de esto, dando un error de este estilo:
library initialization failed - unable to allocate file descriptor table - out of memoryAborted
En mi caso fueron MPlabX y SimplicityStudio las que me dieron problemas, pero parece que ocurre con muchas más aplicaciones Java, y en concreto Android Studio también lo da.
Según una entrada en github, el problema se debe a que Java toma el número máximo de descriptores que se pueden abrir y reserva un bloque de memoria lo suficientemente largo como para albergarlos a todos. Hasta ahora ese número era 4096, con lo que con 16 Kbytes tenía de sobra. Pero tras un cambio en Systemd (pedido, además, por la gente del kernel) dicho número se ha ampliado a 262144 (256 * 1024). En principio esto no debería ser problema (sigue siendo una cifra razonable, y con un mega puede almacenarlo todo), pero, por una serie de desafortunadas circunstancias, Java no recibe esa cifra en Debian SID, sino que, si no hay configurado ningún límite, recibe INFINITY (los detalles se pueden seguir en este hilo de github). El resultado, obviamente, es un error de memoria insuficiente.
Mientras el error no se corrige, es posible parchearlo temporalmente añadiendo esta línea a /etc/security/limits.conf:
* hard nofile 4096
No olvidarse del asterisco al principio. Y en caso de que 4096 no sean suficientes descriptores, se puede aumentar. Un valor máximo razonable es 1048576. Una vez modificado es necesario cerrar la sesión y volver a entrar (o bien reiniciar) para que los cambios surtan efecto.
Por supuesto es bueno revisar de vez en cuando si ya han corregido el bug, y eliminar esa línea cuando ya no sea necesaria.
Java vs. systemd por A cuadros está licenciado bajo una Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.