Liquibase/Springboot启动异常
Liquibase/Springboot startup exception
从昨天(星期日)早上开始,我的生产应用程序无法启动,我这边没有更改代码。它是 运行 Springboot 2.3.4,Liquibase-core 3.8.0,托管在 Amazon linux2 上。
有趣的是本地没有异常,只有在部署时才会出现。
这是相关的堆栈跟踪:
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)
我仔细检查了所有与应用程序相关的文件和环境变量,它们都是一样的。有问题的文件与我的应用程序没有任何关系。
你知道这个文件是什么吗?为什么 Liquibase 会突然试图找到它?
我遇到了同样的问题。在亚马逊linux 2 启动时,安装了一个安全补丁。
导致问题的包是log4j-cve-2021-44228-hotpatch.noarch(你可以在/var/log/yum.log中查看)
一个临时解决方案是卸载补丁并安装另一个 java 版本。
yum remove log4j-cve-2021-44228-hotpatch.noarch
yum install java-11-openjdk-11.0.12.0.7-0.amzn2.0.2.x86_64
感谢@mihristov 的解决方案。
这是一个临时问题:java-11-amazon-corretto-headless-11.0.13+8-2.amzn2.aarch64
修复:
yum remove log4j-cve-2021-44228-hotpatch.noarch
yum install java-11-amazon-corretto-headless-11.0.13+8-1.amzn2.aarch64
感谢@Reda 和@mihristov 指出问题。
我们的实际修复只是安装特定版本的 corretto 而不是通用包
yum install java-11-amazon-corretto-headless-11.0.13+8-1.amzn2.aarch64
您应该只暂时执行此操作,直到修复程序出来!
我们迁移到最新的 liquibase (4+) 解决了这个问题。他们在 4+ 中使用更标准的 ServiceLocator,这似乎有所不同。
详细说明这里发生的事情:
AWS 开发了一个 systemd 服务,它每秒都会在系统上查找任何 JVM 运行。对于它找到并支持的所有内容,它连接一个 java 代理,该代理在运行时用硬编码的安全字符串替换 log4j JNDI lookup()
方法。
我不清楚为什么 liquibase 在这方面失败了。我确实看到已经给出的答案似乎过于具有侵略性。无需 remove/reinstall/update 您的 JVM。您可以通过以下方式解决此问题:
停止系统补丁服务:sudo service log4j-cve-2021-44228-hotpatch status|stop|start
最佳解决方案 - 创建 kill 文件,如果服务读取该文件,则停止应用补丁:sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill
从昨天(星期日)早上开始,我的生产应用程序无法启动,我这边没有更改代码。它是 运行 Springboot 2.3.4,Liquibase-core 3.8.0,托管在 Amazon linux2 上。 有趣的是本地没有异常,只有在部署时才会出现。
这是相关的堆栈跟踪:
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)
我仔细检查了所有与应用程序相关的文件和环境变量,它们都是一样的。有问题的文件与我的应用程序没有任何关系。
你知道这个文件是什么吗?为什么 Liquibase 会突然试图找到它?
我遇到了同样的问题。在亚马逊linux 2 启动时,安装了一个安全补丁。
导致问题的包是log4j-cve-2021-44228-hotpatch.noarch(你可以在/var/log/yum.log中查看)
一个临时解决方案是卸载补丁并安装另一个 java 版本。
yum remove log4j-cve-2021-44228-hotpatch.noarch
yum install java-11-openjdk-11.0.12.0.7-0.amzn2.0.2.x86_64
感谢@mihristov 的解决方案。
这是一个临时问题:java-11-amazon-corretto-headless-11.0.13+8-2.amzn2.aarch64
修复:
yum remove log4j-cve-2021-44228-hotpatch.noarch
yum install java-11-amazon-corretto-headless-11.0.13+8-1.amzn2.aarch64
感谢@Reda 和@mihristov 指出问题。
我们的实际修复只是安装特定版本的 corretto 而不是通用包
yum install java-11-amazon-corretto-headless-11.0.13+8-1.amzn2.aarch64
您应该只暂时执行此操作,直到修复程序出来!
我们迁移到最新的 liquibase (4+) 解决了这个问题。他们在 4+ 中使用更标准的 ServiceLocator,这似乎有所不同。
详细说明这里发生的事情:
AWS 开发了一个 systemd 服务,它每秒都会在系统上查找任何 JVM 运行。对于它找到并支持的所有内容,它连接一个 java 代理,该代理在运行时用硬编码的安全字符串替换 log4j JNDI lookup()
方法。
我不清楚为什么 liquibase 在这方面失败了。我确实看到已经给出的答案似乎过于具有侵略性。无需 remove/reinstall/update 您的 JVM。您可以通过以下方式解决此问题:
停止系统补丁服务:
sudo service log4j-cve-2021-44228-hotpatch status|stop|start
最佳解决方案 - 创建 kill 文件,如果服务读取该文件,则停止应用补丁:
sudo touch /etc/log4j-cve-2021-44228-hotpatch.kill