Hi,
Thanks for providing the logs in your OP!
It looks like they’re really big because you’ve turned them up to DEBUG level. They get really big really fast that way. And it’s really not needed in day-to-day operation. You should turn them back down to INFO as soon as practical.
Regarding your problem, your Background task log references an ES problem, so that’s the log I went to. 35k lines was a bit much to get through, so I just deleted all the DEBUG lines. That left me with a bunch of exceptions like this:
2022.07.08 12:14:21 WARN es[][stderr] java.lang.reflect.InvocationTargetException
2022.07.08 12:14:21 WARN es[][stderr] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/java.lang.reflect.Method.invoke(Method.java:566)
2022.07.08 12:14:21 WARN es[][stderr] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndStartAgent(InstrumentationImpl.java:513)
2022.07.08 12:14:21 WARN es[][stderr] at java.instrument/sun.instrument.InstrumentationImpl.loadClassAndCallAgentmain(InstrumentationImpl.java:535)
2022.07.08 12:14:21 WARN es[][stderr] Caused by: java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "accessClassInPackage.jdk.internal.org.objectweb.asm")
2022.07.08 12:14:21 WARN es[][stderr] at java.base/java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/java.security.AccessController.checkPermission(AccessController.java:897)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/java.lang.SecurityManager.checkPermission(SecurityManager.java:322)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/java.lang.SecurityManager.checkPackageAccess(SecurityManager.java:1238)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:174)
2022.07.08 12:14:21 WARN es[][stderr] at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:522)
2022.07.08 12:14:21 WARN es[][stderr] at Log4jHotPatch.asmVersion(Log4jHotPatch.java:71)
2022.07.08 12:14:21 WARN es[][stderr] at Log4jHotPatch.agentmain(Log4jHotPatch.java:93)
2022.07.08 12:14:21 WARN es[][stderr] ... 6 more
The most interesting part of this for me is
Log4jHotPatch
It seems that you’ve hacked your instance out of concern about the Log4J problems reported in December. There was no need, and you should return to a canonical install immediately.
This thread offers more information:
HTH,
Ann