Re: Cryptominer malware and Tomcat
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Pete, On 6/17/20 17:44, Pete Helgren wrote: > I am going to guess that it is one of these two known > vulnerabilities: > > CST-7111: RCE via JSON deserialization (LPS-88051/LPE-165981) The > JSONDeserializer of Flexjson allows the instantiation of arbitrary > classes and the invocation of arbitrary setter methods. > > CST-7205: Unauthenticated Remote code execution via JSONWS > (LPS-97029/CVE-2020-7961) The JSONWebServiceActionParametersMap of > Liferay Portal allows the instantiation of arbitrary classes and > invocation of arbitrary setter methods. > > Found the signature in the logs and it's pretty clear that that is > what we are up against. However, if something else comes to mind, > feel free to post back. I did come across a couple of other posts > where the OP said there was nothing but Tomcat and they also ended > up with the miner. > > I have some updating to do Definitely update Liferay if these are known vulns. You ought to upgrade Tomcat as well, since 8.0 is no longer supported. 8.0.32 is more than 4 years out of date. Latest 8.0.x release was 8.0.53 before support was dropped in favor of Tomcat 8.5. > The VM running Tomcat/Liferay is served through reverse proxy > listening on port 443 and passes traffic back to the Tomcat > instance listening on 7080. The VM has ONLY ports 7080, 7009, and > 7005 open (firewalld) What is the proxy protocol in use? Are those ports on the Tomcat end only allowing connections from the reverse proxy? What are ports 7009 and 7005 open for? How do you make remote-connections to the server? - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7srPYACgkQHPApP6U8 pFhmbg//Xq/MsdQ0D13iAp3naezwQv59Qmbii2Eboe+0vZp4VHjPX0Il3bT3JRkU 9AvJGwvaN7aPQgOUQjWqaHxTrnIPiQbEMdOuZ7wcWc67Z8cOp5lha/qdgMSvXgMR q/O3o+d6TSQ8sEz4FnabUZPvnebJ6/+azAF3SZUnKXtbLK797CX57m3cefZ4kcEQ UPFcjyXFC81yLBEbUdHTHcH6QOPLeRMzsISd4B4QajZdxOAOaQMqB8hUn/tAfoYu O8nIl6qfQUC3p7JeOVpaacjH2R2mv1pTaFzpedNB0sTRwYkDsXtkmpsz/z02Aej0 /zIdLmIClEjd+IEaqGWGG9uF40EFRAcq+3GJupF7/tHpx72seY8uk/FBlYQQxaBH Q0AXIZmgDcZ0JWnFhnn+N9fcbUVUnqF+sW7wW3JFvLm5mQSLsHYacX0ypLPLvxHX 3Ed44GmIXL+24E/gRqFdq/GnJRAALomM4b8NlFdQPjGZl1MwR41sJIVFi8RcdKA1 wfJ6DK9OcZzVA3a5l3WDtIpnltZbDTZN2rDeTt2m13DuEaZ65vx2Tz4EsjxLLPA2 +wSgCmFVsTmfAvNnFbRQkB1i2GKKxNwTMf74Yee2aAxfwextZp3Iku/ULafLqIWV ZOh7jLiBN+6hm31tdhVRU85sMMEF27EmtInBnEgO3s1z/ZcDYs8= =9Ihv -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Version migration problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Niranjan, On 6/18/20 13:47, Niranjan Rao wrote: > I am trying to migrate from 7.0.73 to 9.0.36 and facing > challenges. > > Java version and operating system version remains same in both > cases. ... and what are those versions? > I have carefully reviewed the configurations and everything looks > ok. Version 9 does not report any problems when starting the > application either in catalina.out file or in the application log > file. Good. > Applications has bunch of JSP pages which sit under > WEB-INF/jsp/pages directory and some of these pages include > fragments from WEB-INF/jsp/fragments directory. In the older > version V7 this works correctly, but in V9 I get error about > include not not found. Page do get resolved correctly, but includes > do not. Can you give some examples? > Given only change is tomcat version as it's same WAR file deployed > on same operating system and same java version, I am thinking I am > missing some basic change in tomcat JSP lookup for version 9. > > > Can anyone please point me what I can be doing wrong or what I need > to do so that same WAR file works in both versions - -chris -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7srVoACgkQHPApP6U8 pFgboBAAsPPfvI5s5NXt7ldN+tub4IBdjYnAqTDtd2Y7Rh2bCZLSjhet6wXIRZcL acRC4o+OE+1Y9RhgTTDKYos9IEIr35WlFLLIRQMhFUjdSBQPbFjlKVIK6YMXJTCp Sbh1IHV/mI+GqsswNaKVDy4l3CueSaUJDB7sw+y/5dbGqWmny+FP4QiR+l8uFofB Yvyu/CilM0SxWpTYUc4Wm6QxXtWbztucSdRRKwKJC6JNnfGhBgZo1q63hjg+NbjZ S6zhz6jc4CSzainEZqiOpJmxryqxUL4LvDfAcST6dmnCxn6Y7LAQd2M78e2reNsX hnR+uNaPr4gPSHibsX6T+oVaXRQdxd05Ws+Fdyu1USIH1K8+cTl7TgEo4Zu92uwx Z2P0OGLq8iWCosvKIQzk2YRq3+Y22UNO8MNMdrl/0NTomDCybNAL/i1PEwH5vCii ylqCMVfk+jzbf91PZWue2ONx10x90NQ70C/I2k5KqkNd2XfnBcNM/BNsFX7SIXpG fkZQHY72YQXC+hkVg4yoyNW9dVOiEQRhH6RTV3Jkjzjmc5NME9dpFn4aYKVG8Zay qAuzz55bVSXcUVVRTUTSefaAsZB7MeUykIe7rSF4Y6wbdidUkbZEVzXHlf8SYXdO EdRjzIddlZJYolbOBGY3uVWOEk4F1ts7EMmUBHsuhekl3wI3Zcc= =BwV+ -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Version migration problems
On 19/06/2020 13:19, Christopher Schultz wrote: > Niranjan, > > On 6/18/20 13:47, Niranjan Rao wrote: >> I am trying to migrate from 7.0.73 to 9.0.36 and facing >> challenges. > >> Java version and operating system version remains same in both >> cases. > > ... and what are those versions? > >> I have carefully reviewed the configurations and everything looks >> ok. Version 9 does not report any problems when starting the >> application either in catalina.out file or in the application log >> file. > > Good. > >> Applications has bunch of JSP pages which sit under >> WEB-INF/jsp/pages directory and some of these pages include >> fragments from WEB-INF/jsp/fragments directory. In the older >> version V7 this works correctly, but in V9 I get error about >> include not not found. Page do get resolved correctly, but includes >> do not. > > Can you give some examples? +1. The simplest test case that demonstrates the issue would be good. That should be a JSP, a JSP fragment and the appropriate directory structure. Mark > >> Given only change is tomcat version as it's same WAR file deployed >> on same operating system and same java version, I am thinking I am >> missing some basic change in tomcat JSP lookup for version 9. > > >> Can anyone please point me what I can be doing wrong or what I need >> to do so that same WAR file works in both versions > > -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: Is it possible to get a callback notification when a http/http2 connection is opened/closed
On 17/06/2020 10:52, Arshiya Shariff wrote: > Hi All, > Can we get a callback notification when a http/http2 connection is > opened/closed in Embedded tomcat . Sorry, no. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Strange crash-on-takeoff, Tomcat 7.0.104
Ladies and Gentlemen: In preparation for updating a customer box, I installed Tomcat 7.0.104 on our own AS/400 (64-bit Java 6 JVM). 7.0.93 works just fine on our box, but 7.0.104 seems to crash on takeoff, producing no log files, just a spool file consisting of the single line *-D Any idea what could be going wrong? -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On Fri, Jun 19, 2020, 15:15 James H. H. Lampert wrote: > Ladies and Gentlemen: > > In preparation for updating a customer box, I installed Tomcat 7.0.104 > on our own AS/400 (64-bit Java 6 JVM). > > 7.0.93 works just fine on our box, but 7.0.104 seems to crash on > takeoff, producing no log files, just a spool file consisting of the > single line > a) are both Tomcat instances installed on that same server? . b) if yes, is the 7.0.93 instance running when you launch the 7.0.104 instance?
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On 19/06/2020 21:14, James H. H. Lampert wrote: > Ladies and Gentlemen: > > In preparation for updating a customer box, I installed Tomcat 7.0.104 > on our own AS/400 (64-bit Java 6 JVM). > > 7.0.93 works just fine on our box, but 7.0.104 seems to crash on > takeoff, producing no log files, just a spool file consisting of the > single line > > *-D > > Any idea what could be going wrong? https://bz.apache.org/bugzilla/show_bug.cgi?id=64501 Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On 6/19/20 3:20 PM, Mark Thomas wrote: https://bz.apache.org/bugzilla/show_bug.cgi?id=64501 Hmm. I'm now looking through the entire catalina.sh script in both versions. (First, I looked through the startup.sh script; that appears to be identical in both versions.) First thing I noticed was that a few new environment variables were listed in the documentation section at the top. Second thing I noticed was the section beginning # Ensure that neither CATALINA_HOME nor CATALINA_BASE contains a colon Third thing I noticed was in the secetion marked "Bugzilla 37848 . . ." old: if [ "`tty`" != "not a tty" ]; then new: if [ -t 0 ]; then Fourth thing I noticed was the section marked # Check for the deprecated LOGGING_CONFIG This looks an awful lot like what's in the Bugzilla page. And I see that it is "Fixed in . . . 7.0.105 onwards." But the download page for 7 is still at 7.0.104. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Version migration problems
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Niranjan, On 6/19/20 13:17, Niranjan Rao wrote: > Hi Mark/Chris, > > Thank you for the reply. > > It's a spring application, related controllers/methods basically > return page name as return "pages/Login". > > The view resolver maps it WEB-INF/jsp/pages/Login.jsp. > > Login.jsp has entry that says > > > > This entry gets resolved correctly in V7, but V9 I get error can > not find pages/jsp/fragments/commonData.jsp. > > After playing with it couple of hours, I figured out full path > works. So issue seems to be root context/directory of jsp engine > that was WEB-INF seems to have changed to current directory where > page is getting loaded. JSP generation still generates same line > for both of them like following. > > org.apache.jasper.runtime.JspRuntimeLibrary.include(request, > response, "jsp/fragments/commonData.jsp", out, false); > > But v9 interprets it relative to directory of current jsp that is > in my case WEB-INF/jsp/pages and older engine interprets it > relative to WEB-INF directory. > > JDK version 1.8.0_111, Operating system is 16.04.6. It's same WAR > file getting deployed in both tomcat versions. Only difference is > server.xml has different ports. I've never done this kind of thing (I tend not to use very many JSPs), but I think you probably want all your file paths to start with "/". So that should be: or maybe: ... unless the path is supposed to be relative to "Login.jsp". Do you have these two files? WEB-INF/pages/Login.jsp WEB-INF/pages/jsp/fragments/commonData.jsp ? If not, then your application isn't built properly. These rules have always been the case, though, so I'm not sure why it would have worked on Tomcat 7 but no longer works on Tomcat 9. - -chris > On 6/19/20 6:13 AM, Mark Thomas wrote: >> On 19/06/2020 13:19, Christopher Schultz wrote: >>> Niranjan, >>> >>> On 6/18/20 13:47, Niranjan Rao wrote: I am trying to migrate from 7.0.73 to 9.0.36 and facing challenges. Java version and operating system version remains same in both cases. >>> ... and what are those versions? >>> I have carefully reviewed the configurations and everything looks ok. Version 9 does not report any problems when starting the application either in catalina.out file or in the application log file. >>> Good. >>> Applications has bunch of JSP pages which sit under WEB-INF/jsp/pages directory and some of these pages include fragments from WEB-INF/jsp/fragments directory. In the older version V7 this works correctly, but in V9 I get error about include not not found. Page do get resolved correctly, but includes do not. >>> Can you give some examples? >> +1. The simplest test case that demonstrates the issue would be >> good. That should be a JSP, a JSP fragment and the appropriate >> directory structure. >> >> Mark >> Given only change is tomcat version as it's same WAR file deployed on same operating system and same java version, I am thinking I am missing some basic change in tomcat JSP lookup for version 9. >>> Can anyone please point me what I can be doing wrong or what I need to do so that same WAR file works in both versions >>> -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 >> > > > - > > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7tHcAACgkQHPApP6U8 pFjqnQ/+LOlgMJirTrnwX/2Bsev2Pxfr80JXx7g9JjAxGTT+ncmYDPnV/xPfNS1m OuZtveZorks4Hvmb62qhSaQWv3GlRwUGn4gYuvSb/EIUX7HWaKJ+f4Zwqjzx0LG/ YAWyK0WeFB4tm9NGjneHGJ5GzfV96WETGNKou38THVAf2nIFBh29kaC9dAd/Pwac zx5Pp2EUGUxwfBR1J3MFoi9XAZnCorpPCKilvtKjn3VMuCvvgQc2CPqarF3NI/S3 EXPRSj5fvQKoAaazEn1IbGbXw1YxkcR9NnV5HUb/+5yYLIbxkpGXcQagt+cbmkJb SBEBsU4q8d7p/ZQYMt7M55P4+kcwpHtPTZwUiKl0u+dI6aw+F/DJONk4adzvvTHu TkAj3DbEuRCegnbGZ8kcYwXRqP5d/CzJh/DCp34neMlGx6fDajuTkY2KfVwcFiZL 6kjPVmym1Gg2csUXjhu0z8T2AbeSFCwm3Fz/Utiqy5OLmhf8Q/mhYiDKdPoT+f9K +9pbidEM0lCLshc0aDR3QOXRLn/jVf3IGc4OrhMniuVYT+kmNRCwtVBCWgc82Xar X+4AwtyGTEgn22gJJ/t0wt+ke0YPrXYvsfR3pk+1XlUZxmRwue/kfduboNsz4FO3 LggXLocMDNPt0FYgUd8pcN4C1n/YxoUgUSxR//I384CdytmfZtU= =OKkM -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 James, On 6/19/20 16:14, James H. H. Lampert wrote: > Ladies and Gentlemen: > > In preparation for updating a customer box, I installed Tomcat > 7.0.104 on our own AS/400 (64-bit Java 6 JVM). > > 7.0.93 works just fine on our box, but 7.0.104 seems to crash on > takeoff, producing no log files, just a spool file consisting of > the single line > > *-D > > Any idea what could be going wrong? What's the name of the file My guess is that the system-property-setting part of catalina.sh (or some other script) is getting fouled-up. What script(s) are you running to start Tomcat? If it's just catalina.sh, try running it like this: $ bash -x $CATALINA_HOME/bin/catalina.sh This will echo every command run to the console before running it, including all expanded arguments and all that stuff. Most likely, the last command run will (a) be the one which is interesting and (b) will be clear from the command what went wrong. - -chris PS You really are a magnet for weird problems with Tomcat, aren't you? -BEGIN PGP SIGNATURE- Comment: Using GnuPG with Thunderbird - https://www.enigmail.net/ iQIzBAEBCAAdFiEEMmKgYcQvxMe7tcJcHPApP6U8pFgFAl7tHuIACgkQHPApP6U8 pFjFNxAAqd4rCgDlMiNNJrECnCpMrX8+sormBO6UBEyE+eAGSpU1AYzyMR2YYzBe gE+dZAjWynoy4lMMBW0t6fiRflCYzJRXNRj7pqn6oA/+vMFLn19raIDSdvGgwkuw L9lDf9uXc7rXPH4ULL2ttkjXfqYjCvWi+06S5CJJemfhXplVaa+VDLVbLlsERDSH KBy/H63q4cmYdj1t0elCQWpLFNa/XoUC84o/TpYAQecgz9lNzi3obN3xXFOXtYBM jZb7SNlcZdCfKMRV/gvkMpdEism4O87kdHCyFyWT6syBiMOhaV9aR88HVTIpUMCX IyC5E7wggyu2SX9Ckit0sJOcET5hjE7EUvwl/EDptCR85sNHXq+wgGaNT/WP3F8J diMe0mh1Al5T5EIK+Nk4Ysac2An7tEVIxob1eWSY59n9FeBu4Jocx2upcZt+VF1T mn0+xMrhFkYiUfdi9IELBcIIAvhlVNyIsZTBmfBXrhtmPXxajGXlNW14KgBinpyi ZmD3G46TWv8H86E/3EsqURGaf2GU2oOuBCjx6VBQca727oE85yBxSE90YgJL/mUe qGEL2BlE9rczv59YVajNl4cBg32Z5VdcRvm6prb/PrViqtnUgKFFUqi2Ki6w41ag YWvvzLtZND1rtqPOMGGdXpJbuoPDJ0xjLVSjs1bnKQj983b/j2M= =x4cd -END PGP SIGNATURE- - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On Fri, Jun 19, 2020, 15:33 James H. H. Lampert wrote: > On 6/19/20 1:26 PM, calder wrote: > > a) are both Tomcat instances installed on that same server? > > Yes > > > b) if yes, is the 7.0.93 instance running when you launch the 7.0.104 > > instance? > > No. > > We've done this procedure before: installing a new version, doing the > setup in the new version, then shutting down the old version, renaming > both the old and the new versions (so things are where they're expected > to be), and starting up. Thanks. a) it's worth asking the obvious ... are the file permissions correct for the new TCp installation, i.e , such as read/write in "logs" subdir and execute permissions for the TC scripts? b) are you using the same Java instance for both TC's ?
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On 6/19/20 1:24 PM, Christopher Schultz wrote: My guess is that the system-property-setting part of catalina.sh (or some other script) is getting fouled-up. What script(s) are you running to start Tomcat? Remember, we're talking about IBM Midrange systems, not *nix. So bash is entirely unknown to the OS; instead, startup.sh calls catalina.sh, with everything running under "QShell," a Linux-like front-end that was provided with Java. If it's just catalina.sh, try running it like this: $ bash -x $CATALINA_HOME/bin/catalina.sh This will echo every command run to the console before running it, including all expanded arguments and all that stuff. Most likely, the last command run will (a) be the one which is interesting and (b) will be clear from the command what went wrong. Unfortunately, QShell doesn't appear to have anyplace to put "-x" as a parameter. But it does appear to support "set -x" at the QShell command line. If I do that, then I get: $ > set -x + set -x $ > catalina.sh + catalina.sh *-D $ PS You really are a magnet for weird problems with Tomcat, aren't you? Well, it comes with the territory of running Tomcat on AS/400s, I suppose. I'm thinking I should bring in the Java list over at Midrange.com as well. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Version migration problems
Hi Mark/Chris, Thank you for the reply. It's a spring application, related controllers/methods basically return page name as return "pages/Login". The view resolver maps it WEB-INF/jsp/pages/Login.jsp. Login.jsp has entry that says This entry gets resolved correctly in V7, but V9 I get error can not find pages/jsp/fragments/commonData.jsp. After playing with it couple of hours, I figured out full path works. So issue seems to be root context/directory of jsp engine that was WEB-INF seems to have changed to current directory where page is getting loaded. JSP generation still generates same line for both of them like following. org.apache.jasper.runtime.JspRuntimeLibrary.include(request, response, "jsp/fragments/commonData.jsp", out, false); But v9 interprets it relative to directory of current jsp that is in my case WEB-INF/jsp/pages and older engine interprets it relative to WEB-INF directory. JDK version 1.8.0_111, Operating system is 16.04.6. It's same WAR file getting deployed in both tomcat versions. Only difference is server.xml has different ports. Regards, Niranjan On 6/19/20 6:13 AM, Mark Thomas wrote: On 19/06/2020 13:19, Christopher Schultz wrote: Niranjan, On 6/18/20 13:47, Niranjan Rao wrote: I am trying to migrate from 7.0.73 to 9.0.36 and facing challenges. Java version and operating system version remains same in both cases. ... and what are those versions? I have carefully reviewed the configurations and everything looks ok. Version 9 does not report any problems when starting the application either in catalina.out file or in the application log file. Good. Applications has bunch of JSP pages which sit under WEB-INF/jsp/pages directory and some of these pages include fragments from WEB-INF/jsp/fragments directory. In the older version V7 this works correctly, but in V9 I get error about include not not found. Page do get resolved correctly, but includes do not. Can you give some examples? +1. The simplest test case that demonstrates the issue would be good. That should be a JSP, a JSP fragment and the appropriate directory structure. Mark Given only change is tomcat version as it's same WAR file deployed on same operating system and same java version, I am thinking I am missing some basic change in tomcat JSP lookup for version 9. Can anyone please point me what I can be doing wrong or what I need to do so that same WAR file works in both versions -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 - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On 6/19/20 1:26 PM, calder wrote: a) are both Tomcat instances installed on that same server? Yes b) if yes, is the 7.0.93 instance running when you launch the 7.0.104 instance? No. We've done this procedure before: installing a new version, doing the setup in the new version, then shutting down the old version, renaming both the old and the new versions (so things are where they're expected to be), and starting up. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
broken pipe error keeps increasing open files
tomcat 8.5 broken pipe increases open files on ubuntu AWS If there is slow response from db I see this stack trace and the open files goes high and the only way to open files go down is to remove the instance from Amazon load balancer. Is there a way to keep the open files low even when Broken pipe error is thrown ? org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken pipe at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:393) at org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) at org.apache.catalina.connector.OutputBuffer.doFlush(OutputBuffer.java:342) at org.apache.catalina.connector.OutputBuffer.flush(OutputBuffer.java:317) at org.apache.catalina.connector.Response.flushBuffer(Response.java:497) at org.apache.catalina.connector.ResponseFacade.flushBuffer(ResponseFacade.java:318) at org.springframework.boot.web.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:126) at org.springframework.boot.web.support.ErrorPageFilter.access$000(ErrorPageFilter.java:61) at org.springframework.boot.web.support.ErrorPageFilter$1.doFilterInternal(ErrorPageFilter.java:94) at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) at org.springframework.boot.web.support.ErrorPageFilter.doFilter(ErrorPageFilter.java:112) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:240) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:207) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:106) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:494) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:141) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79) at org.apache.catalina.valves.AbstractAccessLogValve.invoke(AbstractAccessLogValve.java:616) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:88) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:522) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1095) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:672) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1520) at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.run(NioEndpoint.java:1476) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:748) Caused by: java.io.IOException: Broken pipe at sun.nio.ch.FileDispatcherImpl.write0(Native Method) at sun.nio.ch.SocketDispatcher.write(SocketDispatcher.java:47) at sun.nio.ch.IOUtil.writeFromNativeBuffer(IOUtil.java:93) at sun.nio.ch.IOUtil.write(IOUtil.java:65) at sun.nio.ch.SocketChannelImpl.write(SocketChannelImpl.java:471) at org.apache.tomcat.util.net.NioChannel.write(NioChannel.java:124) at org.apache.tomcat.util.net.NioBlockingSelector.write(NioBlockingSelector.java:101) at org.apache.tomcat.util.net.NioSelectorPool.write(NioSelectorPool.java:172) at org.apache.coyote.http11.InternalNioOutputBuffer.writeToSocket(InternalNioOutputBuffer.java:139) at org.apache.coyote.http11.InternalNioOutputBuffer.addToBB(InternalNioOutputBuffer.java:197) at org.apache.coyote.http11.InternalNioOutputBuffer.access$000(InternalNioOutputBuffer.java:41) at org.apache.coyote.http11.InternalNioOutputBuffer$SocketOutputBuffer.doWrite(InternalNioOutputBuffer.java:320) at org.apache.coyote.http11.filters.ChunkedOutputFilter.doWrite(ChunkedOutputFilter.java:116) at org.apache.coyote.http11.AbstractOutputBuffer.doWrite(AbstractOutputBuffer.java:256) at org.apache.coyote.Response.doWrite(Response.java:501) at org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:388) ... 28 common frames omitted
Re: Strange crash-on-takeoff, Tomcat 7.0.104 (Trying again)
On 6/19/20 1:24 PM, Christopher Schultz wrote: My guess is that the system-property-setting part of catalina.sh (or some other script) is getting fouled-up. What script(s) are you running to start Tomcat? Remember, we're talking about IBM Midrange systems, not *nix. So bash is entirely unknown to the OS; instead, startup.sh calls catalina.sh, with everything running under "QShell," a Linux-like front-end that was provided with Java. If it's just catalina.sh, try running it like this: $ bash -x $CATALINA_HOME/bin/catalina.sh This will echo every command run to the console before running it, including all expanded arguments and all that stuff. Most likely, the last command run will (a) be the one which is interesting and (b) will be clear from the command what went wrong. Unfortunately, QShell doesn't appear to have anyplace to put "-x" as a parameter. But it does appear to support "set -x" at the QShell command line. If I do that, then I get: |$ | > set -x |+ set -x |$ | > catalina.sh |+ catalina.sh |*-D |$ PS You really are a magnet for weird problems with Tomcat, aren't you? Well, it comes with the territory of running Tomcat on AS/400s, I suppose. I'm thinking I should bring in the Java list over at Midrange.com as well. -- JHHL - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Strange crash-on-takeoff, Tomcat 7.0.104
On 6/19/20 2:27 PM, calder wrote:
a) it's worth asking the obvious ... are the file permissions correct for
the new TCp installation, i.e , such as read/write in "logs" subdir and
execute permissions for the TC scripts?
Unless something weird is going on with the apache-tomcat-7.0.104.zip
file, it appears that all the authorities match between old and new
versions.
b) are you using the same Java instance for both TC's ?
Normally, for native-command-line launches, or launches from native CL
programs (like shell scripts, only compiled), we have a CL program
("STRTOMCAT") that does a fair amount of advance setup, selects the
first available JVM from a preference list, and then QShell's out
startup.sh as a batch job. This CL program expects Tomcat to be in a
particular place in the file system, in a directory called "tomcat." So
to switch to a new Tomcat server, I shut the current one down, rename
the current "tomcat" directory to something else (e.g., "tomcat93"), and
rename the "apache-tomcat-7.0.104" directory to "tomcat" before starting
it with STRTOMCAT.
So it would *have* to be the same JVM, because that's explicitly
selected by the STRTOMCAT CL program.
--
JHHL
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
