Re: [OT] Log4j 2.15.0 and Tomcat 9.0.56
I was a bug in at AbstractClassFinder.java:216 (com.ocpsoft.pretty.faces.config.annotation.AbstractClassFinder.processClass) Sorry and thanks for your tips! On Mon, Dec 20, 2021 at 4:53 PM Christopher Schultz wrote: > > Daniela, > > On 12/20/21 13:15, Daniela Morais wrote: > > I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing > > this issue. Is there any workaround or the only option is to upgrade > > Java? > > Note that if you are trying to "upgrade to the latest log4j" due to > revent CVEs, you want 2.17.0 and not 2.15.0. > > -chris > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -- Daniela Morais Software Engineer +55 19 994-868-865 | linkedin danielammorais.com - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Async WriteListener#onWritePossible not getting called
On Sat, Dec 18, 2021 at 11:09 AM Mark Thomas wrote: > > On 15/12/2021 22:23, Samuel Cox wrote: > > Hello, > > > > We are using tomcat-embedded 9.0.55. OS is mac 10.15.7. We have > > quite a bit of config, but I'm guessing the most relevant is that we > > use the NIO2 protocol. > > > > We have been working on a reproducer, but we have many, many layers > > involved. However, I believe what we are experiencing is described in > > this old mailing list post: > > https://www.mail-archive.com/users@tomcat.apache.org/msg124043.html > > > > In our case, we are registering a listener on for request 1 on a > > container thread for a request-other-than-1. > > That is unusual. I don't see any obvious reason why that wouldn't work > but equally, I could well believe that in that scenario correct > operation would be very dependent on timing. I'm not sure that the API > exposes everything you would need to make sure that it would always work. > > > When that happens, onWritePossible never fires. > > That the behaviour is consistent at least means it should be easy to debug. > > > We do not have this problem when we run > > with Jetty and the thread usage looks very similar. > > > > I still see that marked as @Ignore in the 9.0.x source. Is this still > > viewed as an issue? > > I can't find anything in the commit log or on the dev list that would > explain why this issue wasn't resolved. > > > I'm trying to get ant installed so I can run the > > test:) > > It fails. > > I suggest opening a Bugzilla issue either it isn't forgotten or if there > is a good reason for not fixing it, we have that reason documented. > Include a reference to the test. Done. It can be found at https://bz.apache.org/bugzilla/show_bug.cgi?id=65757 > Mark > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [OT] Log4j 2.15.0 and Tomcat 9.0.56
Daniela, On 12/20/21 13:15, Daniela Morais wrote: I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing this issue. Is there any workaround or the only option is to upgrade Java? Note that if you are trying to "upgrade to the latest log4j" due to revent CVEs, you want 2.17.0 and not 2.15.0. -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: thread pool count never goes down
Jon, On 12/19/21 12:19, Jonathan Yom-Tov wrote: hi Chris, Sorry for the late reply, I didn't see your reply for some reason. Here's the relevant connector configuration: You are allowing Tomcat to automatically-configure an "Executor" for you, and that executor will never shed threads. You need to change your configuration so that you have this: You can read more about the configuration of executors here: https://tomcat.apache.org/tomcat-9.0-doc/config/executor.html Note that your current configuration has separate thread-pools, one for each . If you specify the "executor" configuration attribute, you can choose to share a single or have separate ones for each . If you want them separate, just define two of them and reference them appropriately. Hope that helps, -chris On Tue, Dec 7, 2021 at 10:28 PM Christopher Schultz < ch...@christopherschultz.net> wrote: Jon, On 12/6/21 10:28, Jonathan Yom-Tov wrote: I have a single instance of Tomcat (version 9.0.54) in which the thread count on a connector thread pool doesn't reduce despite most of the threads (198/200) being idle. If I understand correctly the default idle time before a thread is reaped is 60 seconds, but this situation persists for hours. Any ideas for why this could happen? Maybe. Can you post your configuration? -chris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Log4j 2.15.0 and Tomcat 9.0.56
that is a class that is being loaded on java 8 and it wants java 9 but log4j as far as i know supports even java 7.. so i have a feeling that can't be it (that it won't run on java 8) On Mon, 20 Dec 2021 at 19:15, Daniela Morais wrote: > I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing > this issue. Is there any workaround or the only option is to upgrade > Java? > > Configs > Java 8 > Tomcat 9.0.56 > > Log > 20-Dec-2021 15:10:45.177 SEVERE [RMI TCP Connection(2)-127.0.0.1] > org.apache.catalina.core.StandardContext.listenerStart Exception > sending context initialized event to listener instance of class > [org.ocpsoft.rewrite.servlet.impl.RewriteServletContextListener] > java.lang.UnsupportedClassVersionError: > META-INF/versions/9/module-info has been compiled by a more recent > version of the Java Runtime (class file version 53.0), this version of > the Java Runtime only recognizes class file versions up to 52.0 > (unable to load class [META-INF.versions.9.module-info]) > at > org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2483) > at > org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870) > at > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371) > at > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215) > at > com.ocpsoft.pretty.faces.config.annotation.AbstractClassFinder.processClass(AbstractClassFinder.java:216) > at > com.ocpsoft.pretty.faces.config.annotation.WebLibFinder.processJarFile(WebLibFinder.java:141) > at > com.ocpsoft.pretty.faces.config.annotation.WebLibFinder.findClasses(WebLibFinder.java:85) > at > com.ocpsoft.pretty.faces.config.spi.AnnotationConfigurationProvider.loadConfiguration(AnnotationConfigurationProvider.java:82) > at > com.ocpsoft.pretty.faces.config.PrettyConfigurator.configure(PrettyConfigurator.java:63) > at > org.ocpsoft.rewrite.prettyfaces.PrettyConfigContextListener.contextInitialized(PrettyConfigContextListener.java:41) > at > org.ocpsoft.rewrite.servlet.impl.RewriteServletContextListener.contextInitialized(RewriteServletContextListener.java:38) > at > org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4768) > at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5230) > at > org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) > at > org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1783) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:293) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at > org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:460) > at > org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:408) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:498) > at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:293) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) > at > com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468) > at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468) > at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) > at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309) > at java.security.AccessController.doPrivileged(Native Method) > at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1408) >
Re: Log4j 2.15.0 and Tomcat 9.0.56
We are running Tomcat 9 on Java 11 without any issues, but you probably want to test it with your application. > Am 20.12.2021 um 19:15 schrieb Daniela Morais : > > I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing > this issue. Is there any workaround or the only option is to upgrade > Java? > > Configs > Java 8 > Tomcat 9.0.56 > > Log > 20-Dec-2021 15:10:45.177 SEVERE [RMI TCP Connection(2)-127.0.0.1] > org.apache.catalina.core.StandardContext.listenerStart Exception > sending context initialized event to listener instance of class > [org.ocpsoft.rewrite.servlet.impl.RewriteServletContextListener] >java.lang.UnsupportedClassVersionError: > META-INF/versions/9/module-info has been compiled by a more recent > version of the Java Runtime (class file version 53.0), this version of > the Java Runtime only recognizes class file versions up to 52.0 > (unable to load class [META-INF.versions.9.module-info]) >at > org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2483) >at > org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870) >at > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371) >at > org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215) >at > com.ocpsoft.pretty.faces.config.annotation.AbstractClassFinder.processClass(AbstractClassFinder.java:216) >at > com.ocpsoft.pretty.faces.config.annotation.WebLibFinder.processJarFile(WebLibFinder.java:141) >at > com.ocpsoft.pretty.faces.config.annotation.WebLibFinder.findClasses(WebLibFinder.java:85) >at > com.ocpsoft.pretty.faces.config.spi.AnnotationConfigurationProvider.loadConfiguration(AnnotationConfigurationProvider.java:82) >at > com.ocpsoft.pretty.faces.config.PrettyConfigurator.configure(PrettyConfigurator.java:63) >at > org.ocpsoft.rewrite.prettyfaces.PrettyConfigContextListener.contextInitialized(PrettyConfigContextListener.java:41) >at > org.ocpsoft.rewrite.servlet.impl.RewriteServletContextListener.contextInitialized(RewriteServletContextListener.java:38) >at > org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4768) >at > org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5230) >at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) >at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) >at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) >at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) >at > org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1783) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:498) >at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:293) >at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) >at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) >at > org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:460) >at > org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:408) >at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >at java.lang.reflect.Method.invoke(Method.java:498) >at > org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:293) >at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) >at > com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) >at > com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468) >at > javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468) >at > javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) >at > javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309) >at java.security.AccessController.doPrivileged(Native Method) >at > javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1408) >at >
Log4j 2.15.0 and Tomcat 9.0.56
I'm trying to upgrade Log4j2 dependencies to 2.15.0 and I'm facing this issue. Is there any workaround or the only option is to upgrade Java? Configs Java 8 Tomcat 9.0.56 Log 20-Dec-2021 15:10:45.177 SEVERE [RMI TCP Connection(2)-127.0.0.1] org.apache.catalina.core.StandardContext.listenerStart Exception sending context initialized event to listener instance of class [org.ocpsoft.rewrite.servlet.impl.RewriteServletContextListener] java.lang.UnsupportedClassVersionError: META-INF/versions/9/module-info has been compiled by a more recent version of the Java Runtime (class file version 53.0), this version of the Java Runtime only recognizes class file versions up to 52.0 (unable to load class [META-INF.versions.9.module-info]) at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:2483) at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:870) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1371) at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1215) at com.ocpsoft.pretty.faces.config.annotation.AbstractClassFinder.processClass(AbstractClassFinder.java:216) at com.ocpsoft.pretty.faces.config.annotation.WebLibFinder.processJarFile(WebLibFinder.java:141) at com.ocpsoft.pretty.faces.config.annotation.WebLibFinder.findClasses(WebLibFinder.java:85) at com.ocpsoft.pretty.faces.config.spi.AnnotationConfigurationProvider.loadConfiguration(AnnotationConfigurationProvider.java:82) at com.ocpsoft.pretty.faces.config.PrettyConfigurator.configure(PrettyConfigurator.java:63) at org.ocpsoft.rewrite.prettyfaces.PrettyConfigContextListener.contextInitialized(PrettyConfigContextListener.java:41) at org.ocpsoft.rewrite.servlet.impl.RewriteServletContextListener.contextInitialized(RewriteServletContextListener.java:38) at org.apache.catalina.core.StandardContext.listenerStart(StandardContext.java:4768) at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5230) at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:183) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:726) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:698) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:696) at org.apache.catalina.startup.HostConfig.manageApp(HostConfig.java:1783) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:293) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:460) at org.apache.catalina.mbeans.MBeanFactory.createStandardContext(MBeanFactory.java:408) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at org.apache.tomcat.util.modeler.BaseModelMBean.invoke(BaseModelMBean.java:293) at com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.invoke(DefaultMBeanServerInterceptor.java:819) at com.sun.jmx.mbeanserver.JmxMBeanServer.invoke(JmxMBeanServer.java:801) at com.sun.jmx.remote.security.MBeanServerAccessController.invoke(MBeanServerAccessController.java:468) at javax.management.remote.rmi.RMIConnectionImpl.doOperation(RMIConnectionImpl.java:1468) at javax.management.remote.rmi.RMIConnectionImpl.access$300(RMIConnectionImpl.java:76) at javax.management.remote.rmi.RMIConnectionImpl$PrivilegedOperation.run(RMIConnectionImpl.java:1309) at java.security.AccessController.doPrivileged(Native Method) at javax.management.remote.rmi.RMIConnectionImpl.doPrivilegedOperation(RMIConnectionImpl.java:1408) at javax.management.remote.rmi.RMIConnectionImpl.invoke(RMIConnectionImpl.java:829) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at
Re: tomcat 10.0.14 startup and shutdown
You might try adding "RemainAfterExit=yes" to your service definition (in the Service block). Also, try looking at the journald logs for catalina and systemd; they might give you more clues as to what is happening (sudo journalctl -t systemd and sudo journalctl -t catalina). On Mon, Dec 20, 2021 at 6:09 AM Pietro Maria Liuzzo < pietro.liu...@uni-hamburg.de> wrote: > Dear all, > > sorry, I rarely work with tomcat, now I upgraded from 9 to 10 and I am > having troubles even before putting my .war applications in, I hope someone > can point me to my mistake. > > I have installed tomcat with brew on Ubuntu 18. It was installed in > /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/ beside the previous > version 9, which got cleared of its contents beside libexec. > > I then went on to modify my server.xml with port 8081 instead of 8080, > where I have another application running. > > I changed owner to tomcat:tomcat to the directory > /home/linuxbrew/.linuxbrew/Cellar/tomcat > > then I went on to my tomcat.service and modified like this (for the > version number) > > [Unit] > Description=Tomcat 10 servlet container > After=network.target > > [Service] > Type=forking > > > Environment=JAVA_HOME=/usr/lib/jvm/default-java > Environment=JRE_HOME=/home/linuxbrew/.linuxbrew/opt/openjdk > Environment=JAVA_OPTS="-Djava.security.egd=file:///dev/urandom > -Djava.awt.headless=true" > > > Environment=CATALINA_BASE=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec > > Environment=CATALINA_HOME=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec > > Environment=CATALINA_PID=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/temp/tomcat.pid > Environment=CATALINA_OPTS="-Xms512M -Xmx1024M -server -XX:+UseParallelGC" > > ExecStart=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/bin/catalina > start > ExecStop=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/bin/catalina stop > > User=tomcat > Group=tomcat > > [Install] > WantedBy=multi-user.target > > > If I start with bin/catalina start > > I get > Using CATALINA_BASE: > /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec > Using CATALINA_HOME: > /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec > Using CATALINA_TMPDIR: > /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/temp > Using JRE_HOME:/usr/lib/jvm/default-java > Using CLASSPATH: > > /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/bin/bootstrap.jar:/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/bin/tomcat-juli.jar > Using CATALINA_OPTS: > Tomcat started. > > If I start with sudo systemctl start tomcat and then I test with systemctl > status tomcat I get > > tomcat.service - Tomcat 10 servlet container >Loaded: loaded (/etc/systemd/system/tomcat.service; disabled; vendor > preset: enabled) >Active: failed (Result: exit-code) since Mon 2021-12-20 13:44:26 CET; > 4s ago > Process: 7592 > ExecStart=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/bin/catalina > start (code=exited, status=0/SU > Main PID: 7612 (code=exited, status=1/FAILURE) > > Dec 20 13:44:26 betamasaheft2 systemd[1]: Starting Tomcat 10 servlet > container... > Dec 20 13:44:26 betamasaheft2 catalina[7592]: Existing PID file found > during start. > Dec 20 13:44:26 betamasaheft2 catalina[7592]: Removing/clearing stale PID > file. > Dec 20 13:44:26 betamasaheft2 catalina[7592]: Tomcat started. > Dec 20 13:44:26 betamasaheft2 systemd[1]: Started Tomcat 10 servlet > container. > Dec 20 13:44:26 betamasaheft2 systemd[1]: tomcat.service: Main process > exited, code=exited, status=1/FAILURE > Dec 20 13:44:26 betamasaheft2 systemd[1]: tomcat.service: Failed with > result 'exit-code'. > > the log in catalina.2021-12-20.log tells me > > 20-Dec-2021 13:34:17.081 INFO [main] > org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler > ["http-nio-8081"] > 20-Dec-2021 13:34:17.103 INFO [main] > org.apache.catalina.startup.Catalina.start Server startup in [2513] > milliseconds > 20-Dec-2021 13:35:21.613 INFO [main] > org.apache.catalina.core.StandardServer.await A valid shutdown command was > received via the shutdown port. Stopping the Server instance. > 20-Dec-2021 13:35:21.614 INFO [main] > org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler > ["http-nio-8081"] > 20-Dec-2021 13:35:21.625 INFO [main] > org.apache.catalina.core.StandardService.stopInternal Stopping service > [Catalina] > 20-Dec-2021 13:35:21.702 INFO [main] > org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler > ["http-nio-8081"] > 20-Dec-2021 13:35:21.711 INFO [main] > org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler > ["http-nio-8081“] > > > Which to me looks like „I started, and then I shut down“. I do not > understand where is the button which the hand clicks to close it self once > it has been triggered out to the box. It feels to me like I have changed > and tried with every combination of quotes, lines included and excluded, > changes of port and reassigning
tomcat 10.0.14 startup and shutdown
Dear all, sorry, I rarely work with tomcat, now I upgraded from 9 to 10 and I am having troubles even before putting my .war applications in, I hope someone can point me to my mistake. I have installed tomcat with brew on Ubuntu 18. It was installed in /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/ beside the previous version 9, which got cleared of its contents beside libexec. I then went on to modify my server.xml with port 8081 instead of 8080, where I have another application running. I changed owner to tomcat:tomcat to the directory /home/linuxbrew/.linuxbrew/Cellar/tomcat then I went on to my tomcat.service and modified like this (for the version number) [Unit] Description=Tomcat 10 servlet container After=network.target [Service] Type=forking Environment=JAVA_HOME=/usr/lib/jvm/default-java Environment=JRE_HOME=/home/linuxbrew/.linuxbrew/opt/openjdk Environment=JAVA_OPTS="-Djava.security.egd=file:///dev/urandom -Djava.awt.headless=true" Environment=CATALINA_BASE=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec Environment=CATALINA_HOME=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec Environment=CATALINA_PID=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/temp/tomcat.pid Environment=CATALINA_OPTS="-Xms512M -Xmx1024M -server -XX:+UseParallelGC" ExecStart=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/bin/catalina start ExecStop=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/bin/catalina stop User=tomcat Group=tomcat [Install] WantedBy=multi-user.target If I start with bin/catalina start I get Using CATALINA_BASE: /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec Using CATALINA_HOME: /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec Using CATALINA_TMPDIR: /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/temp Using JRE_HOME:/usr/lib/jvm/default-java Using CLASSPATH: /home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/bin/bootstrap.jar:/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/libexec/bin/tomcat-juli.jar Using CATALINA_OPTS: Tomcat started. If I start with sudo systemctl start tomcat and then I test with systemctl status tomcat I get tomcat.service - Tomcat 10 servlet container Loaded: loaded (/etc/systemd/system/tomcat.service; disabled; vendor preset: enabled) Active: failed (Result: exit-code) since Mon 2021-12-20 13:44:26 CET; 4s ago Process: 7592 ExecStart=/home/linuxbrew/.linuxbrew/Cellar/tomcat/10.0.14/bin/catalina start (code=exited, status=0/SU Main PID: 7612 (code=exited, status=1/FAILURE) Dec 20 13:44:26 betamasaheft2 systemd[1]: Starting Tomcat 10 servlet container... Dec 20 13:44:26 betamasaheft2 catalina[7592]: Existing PID file found during start. Dec 20 13:44:26 betamasaheft2 catalina[7592]: Removing/clearing stale PID file. Dec 20 13:44:26 betamasaheft2 catalina[7592]: Tomcat started. Dec 20 13:44:26 betamasaheft2 systemd[1]: Started Tomcat 10 servlet container. Dec 20 13:44:26 betamasaheft2 systemd[1]: tomcat.service: Main process exited, code=exited, status=1/FAILURE Dec 20 13:44:26 betamasaheft2 systemd[1]: tomcat.service: Failed with result 'exit-code'. the log in catalina.2021-12-20.log tells me 20-Dec-2021 13:34:17.081 INFO [main] org.apache.coyote.AbstractProtocol.start Starting ProtocolHandler ["http-nio-8081"] 20-Dec-2021 13:34:17.103 INFO [main] org.apache.catalina.startup.Catalina.start Server startup in [2513] milliseconds 20-Dec-2021 13:35:21.613 INFO [main] org.apache.catalina.core.StandardServer.await A valid shutdown command was received via the shutdown port. Stopping the Server instance. 20-Dec-2021 13:35:21.614 INFO [main] org.apache.coyote.AbstractProtocol.pause Pausing ProtocolHandler ["http-nio-8081"] 20-Dec-2021 13:35:21.625 INFO [main] org.apache.catalina.core.StandardService.stopInternal Stopping service [Catalina] 20-Dec-2021 13:35:21.702 INFO [main] org.apache.coyote.AbstractProtocol.stop Stopping ProtocolHandler ["http-nio-8081"] 20-Dec-2021 13:35:21.711 INFO [main] org.apache.coyote.AbstractProtocol.destroy Destroying ProtocolHandler ["http-nio-8081“] Which to me looks like „I started, and then I shut down“. I do not understand where is the button which the hand clicks to close it self once it has been triggered out to the box. It feels to me like I have changed and tried with every combination of quotes, lines included and excluded, changes of port and reassigning of premissions. Thanks a lot for any help you can give me. all best Pietro Pietro Maria Liuzzo (egli/lui,he/him,er/ihn) Hiob Ludolf Centre for Ethiopian Studies Room: 136 Alsterterrasse 1 20354 Hamburg Tel: +49 40 42838-8381 ORCID: https://orcid.org/-0001-5714-4011 Academia: https://uni-hamburg.academia.edu/PietroMariaLiuzzo
Re: Critical Random "Can't read cryptographic policy directory: unlimited"
On 20/12/2021 06:59, Jerry Malcolm wrote:
I'm adding a slight variation to the error I get at times (see bottom of
stack trace below)
This is the code that throws the root exception:
if (!Files.isDirectory(cryptoPolicyPath)
|| !Files.isReadable(cryptoPolicyPath)) {
throw new SecurityException(
"Can't read cryptographic policy directory: " +
cryptoPolicyProperty);
}
That points very strongly to a file system issue. My recommendation is
to take this up with AWS support.
Mark
On 12/19/2021 11:55 PM, Jerry Malcolm wrote:
I have a production environment of 10+ AWS EC2 servers all built from
a single EC2 snapshot image. The master EC2 works fine. But when we
propagated the image to all of the production servers, we started
getting "Can't read cryptographic policy directory: unlimited" errors
when I try to get a jdbc connection object from the pool. Full stack
trace is below. The three critical lines in the trace are:
java.lang.ExceptionInInitializerError
Caused by: java.lang.SecurityException: Can not initialize
cryptographic mechanism
Caused by: java.lang.SecurityException: Can't read cryptographic
policy directory: unlimited
On some machines rebooting the tomcat service fixes the problem and it
continues to work fine after that. On other machines, the problem is
still there after rebooting. But even on the machines that are fixed
after TC bounce, if I bounce the full EC2, the problem is back.
We've had this environment working for almost two years. I did a
minor version upgrade to TC 8.5.73 a month ago. And I upgraded to
java 11 probably a year ago. Otherwise, no changes that I'm aware
of. Definitely nothing in the past few days before the error hit
yesterday.
Everything I can find on google about the error messages says to make
sure the 'unlimited' folder is present and accessible. The folder is
there and has been there untouched. And I know it's not disappearing
and reappearing to become accessible after the TC reboot that
sometimes fixes the problem.
The mySQL RDS all of these instances talk to hasn't changed. And
other servers that aren't part of this image distribution have no
problems accessing it. It just makes no sense that the same EC2 image
that works on one machine started failing on a bunch of identical
configuration EC2s yesterday.
I know this call goes through layers of tomcat, layers of the mysql
driver, and then layers of the jvm before it occurs. But can anyone
help me understand what TC/mySQL might be trying to do with this call
to JVM crypto code and why it has started failing on all of my
servers? Any Java crypto gurus out there?
Stack trace of error:
java.lang.ExceptionInInitializerError
at java.base/javax.crypto.Cipher.getInstance(Cipher.java:540)
at java.base/sun.security.ssl.JsseJce.getCipher(JsseJce.java:185)
at
java.base/sun.security.ssl.SSLCipher.isTransformationAvailable(SSLCipher.java:483)
at java.base/sun.security.ssl.SSLCipher.(SSLCipher.java:472)
at java.base/sun.security.ssl.SSLCipher.(SSLCipher.java:81)
at java.base/sun.security.ssl.CipherSuite.(CipherSuite.java:67)
at
java.base/sun.security.ssl.SSLContextImpl.getApplicableSupportedCipherSuites(SSLContextImpl.java:348)
at
java.base/sun.security.ssl.SSLContextImpl$AbstractTLSContext.(SSLContextImpl.java:580)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:315)
at
java.base/java.security.Provider$Service.getImplClass(Provider.java:1918)
at
java.base/java.security.Provider$Service.newInstance(Provider.java:1894)
at
java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:236)
at
java.base/sun.security.jca.GetInstance.getInstance(GetInstance.java:164)
at java.base/javax.net.ssl.SSLContext.getInstance(SSLContext.java:168)
at
com.mysql.cj.protocol.ExportControlled.getSSLContext(ExportControlled.java:565)
at
com.mysql.cj.protocol.ExportControlled.performTlsHandshake(ExportControlled.java:302)
at
com.mysql.cj.protocol.StandardSocketFactory.performTlsHandshake(StandardSocketFactory.java:188)
at
com.mysql.cj.protocol.a.NativeSocketConnection.performTlsHandshake(NativeSocketConnection.java:99)
at
com.mysql.cj.protocol.a.NativeProtocol.negotiateSSLConnection(NativeProtocol.java:331)
at
com.mysql.cj.protocol.a.NativeAuthenticationProvider.negotiateSSLConnection(NativeAuthenticationProvider.java:777)
at
com.mysql.cj.protocol.a.NativeAuthenticationProvider.proceedHandshakeWithPluggableAuthentication(NativeAuthenticationProvider.
at
com.mysql.cj.protocol.a.NativeAuthenticationProvider.connect(NativeAuthenticationProvider.java:202)
at
com.mysql.cj.protocol.a.NativeProtocol.connect(NativeProtocol.java:1348)
at com.mysql.cj.NativeSession.connect(NativeSession.java:163)
at
com.mysql.cj.jdbc.ConnectionImpl.connectOneTryOnly(ConnectionImpl.java:947)
at com.mysql.cj.jdbc.ConnectionImpl.createNewIO(ConnectionImpl.java:817)
at
