A partir de ayer (domingo) por la mañana, mi aplicación de producción no se inicia, sin cambios en el código por mi parte. Está ejecutando Springboot 2.3.4, Liquibase-core 3.8.0 y está alojado en Amazon linux2. Lo curioso es que no hay excepciones localmente, solo cuando se implementa.
Aquí está el seguimiento de la pila relevante:
Caused by: liquibase.exception.UnexpectedLiquibaseException: java.nio.file.NoSuchFileException: /tmp/agent12302722365010540729.jar at liquibase.servicelocator.ServiceLocator.setResourceAccessor(ServiceLocator.java:129) at liquibase.servicelocator.ServiceLocator.<init>(ServiceLocator.java:69) at liquibase.servicelocator.CustomResolverServiceLocator.<init>(CustomResolverServiceLocator.java:16) at org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener$LiquibasePresent.replaceServiceLocator(LiquibaseServiceLocatorApplicationListener.java:55) at org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener.onApplicationEvent(LiquibaseServiceLocatorApplicationListener.java:44) at org.springframework.boot.liquibase.LiquibaseServiceLocatorApplicationListener.onApplicationEvent(LiquibaseServiceLocatorApplicationListener.java:36) ... Caused by: java.nio.file.NoSuchFileException: /tmp/agent801508645517312012.jar at liquibase.resource.ClassLoaderResourceAccessor.getResourcesAsStream(ClassLoaderResourceAccessor.java:53) at liquibase.servicelocator.ServiceLocator.setResourceAccessor(ServiceLocator.java:115)Verifiqué dos veces todos los archivos relacionados con la aplicación y las variables env y todos son iguales. El archivo en cuestión no está relacionado de ninguna manera con mi aplicación.
¿Tiene alguna idea de qué es este archivo y por qué Liquibase intenta encontrarlo de repente?
Yo tuve el mismo problema. En el inicio de Amazon Linux 2, hay un parche de seguridad instalado.
El paquete que causa el problema es log4j-cve-2021-44228-hotpatch.noarch (puede comprobarlo en /var/log/yum.log)
Una solución temporal es desinstalar el parche e instalar otra versión de Java.
yum remove log4j-cve-2021-44228-hotpatch.noarch yum install java-11-openjdk-11.0.12.0.7-0.amzn2.0.2.x86_64Gracias a @mihristov por la solución.
Este es un problema temporal con: java-11-amazon-corretto-headless-11.0.13+8-2.amzn2.aarch64
Arreglar:
yum remove log4j-cve-2021-44228-hotpatch.noarch yum install java-11-amazon-corretto-headless-11.0.13+8-1.amzn2.aarch64Gracias a @Reda y @mihristov por señalar el problema.
Nuestra solución real fue simplemente instalar una versión específica de corretto en lugar del paquete general
yum install java-11-amazon-corretto-headless-11.0.13+8-1.amzn2.aarch64¡Solo debe hacer esto temporalmente hasta que se encuentre una solución!
Para nosotros, mudarnos a la última liquibase (4+) resolvió esto. Usan un ServiceLocator más estándar en 4+ y eso parece marcar la diferencia.
Para elaborar un poco más sobre lo que está sucediendo aquí:
AWS ha desarrollado un servicio systemd que, cada segundo, busca cualquier JVM que se esté ejecutando en el sistema. Por todo lo que encuentra y lo admite, conecte un agente Java que en tiempo de ejecución reemplaza el método log4j JNDI lookup() con una cadena segura codificada.
No me queda claro por qué liquibase falla en esto. Veo que las respuestas ya dadas parecen ser demasiado invasivas. No es necesario eliminar/reinstalar/actualizar su JVM. Puede solucionar esto de la siguiente manera:
Detención del servicio de parche systemd: sudo service log4j-cve-2021-44228-hotpatch status|stop|start
La mejor solución: cree el archivo de eliminación que, si lo lee el servicio, deja de aplicar el parche: sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill