Return-Path: X-Original-To: apmail-tomcat-users-archive@www.apache.org Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 33C7E10A50 for ; Fri, 18 Oct 2013 20:17:09 +0000 (UTC) Received: (qmail 95181 invoked by uid 500); 18 Oct 2013 20:17:00 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 95086 invoked by uid 500); 18 Oct 2013 20:16:56 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 95064 invoked by uid 99); 18 Oct 2013 20:16:54 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Oct 2013 20:16:54 +0000 X-ASF-Spam-Status: No, hits=1.6 required=5.0 tests=RCVD_IN_BRBL_LASTEXT,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [79.34.33.2] (HELO elrond.aspix.it) (79.34.33.2) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 18 Oct 2013 20:16:50 +0000 Received: from base-ithilien.local ([192.168.1.20] helo=shadowfax.local) by elrond.aspix.it with esmtp (Exim 4.69) (envelope-from ) id 1VXGM0-0000PQ-HI for users@tomcat.apache.org; Fri, 18 Oct 2013 22:09:00 +0200 Message-ID: <5261971A.6020200@aspix.it> Date: Fri, 18 Oct 2013 22:16:26 +0200 From: Edoardo Panfili User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.0.1 MIME-Version: 1.0 To: users@tomcat.apache.org Subject: Re: can't connect to manager application References: <5260142A.1030509@aspix.it> <52604BD7.5090200@gmail.com> <5260C86C.10609@aspix.it> <5260D895.3040001@gmail.com> <526132C2.9080009@aspix.it> <5261485E.8090005@ice-sa.com>,<52615C03.8000100@aspix.it> <526163EC.8090200@aspix.it> <52616496.7040508@christopherschultz.net> <52616648.5060207@ice-sa.com> <52616841.9080506@christopherschultz.net> <52616D43.9090702@ice-sa.com> <52617948.4090601@aspix.it> <52618858.30008@ice-sa.com> In-Reply-To: <52618858.30008@ice-sa.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Virus-Checked: Checked by ClamAV on apache.org Il 18/10/13 21:13, André Warnier ha scritto: > Edoardo Panfili wrote: >> Il 18/10/13 19:17, André Warnier ha scritto: >>> Christopher Schultz wrote: >>>> -----BEGIN PGP SIGNED MESSAGE----- >>>> Hash: SHA256 >>>> >>>> André, >>>> >>>> On 10/18/13 12:48 PM, André Warnier wrote: >>>>> Christopher Schultz wrote: >>>>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 >>>>>> >>>>>> Edoardo, >>>>>> >>>>>> On 10/18/13 12:38 PM, Edoardo Panfili wrote: >>>>>>> Il 18/10/13 18:29, Martin Gainty ha scritto: >>>>>>>>> Date: Fri, 18 Oct 2013 18:04:19 +0200 From: >>>>>>>>> edoardo@aspix.it To: users@tomcat.apache.org Subject: Re: >>>>>>>>> can't connect to manager application >>>>>>>>> >>>>>>>>> Il 18/10/13 16:40, André Warnier ha scritto: >>>>>>>>>> Edoardo Panfili wrote: >>>>>>>>>>> Il 18/10/13 08:43, Ognjen Blagojevic ha scritto: >>>>>>>>>>>> On 18.10.2013 7:34, Edoardo Panfili wrote: >>>>>>>>>>>>>> To rule out faulty upgrade, could you try to reproduce the >>>>>>>>>>>>>> problem on clean Tomcat 7.0.42 install? >>>>>>>>>>>>> the problem was surely present with 7.0.39, the >>>>>>>>>>>>> 7.0.42 is a fresh installation for me. >>>>>>>>>>>> Could you please clarify: does the problem exists on 7.0.42, >>>>>>>>>>>> 7.0.39 or both? >>>>>>>>>>> both >>>>>>>>>>> >>>>>>>>>>>> Could you provide steps to reproduce the problem on >>>>>>>>>>>> fresh 7.0.42 installation? >>>>>>>>>>> - unpack tomcat - modify listen port - modify tomcat-users.xml >>>>>>>>>>> - copy jmxremote.access and jmxremote.password (setting >>>>>>>>>>> permissions) - build jsvc >>>>>>>>>>> - copy configuration files for applications (in >>>>>>>>>>> $tomcat/conf/Catalina/localhost) >>>>>>>>>>> >>>>>>>>>>> thank you for you question: also jmx remote access is >>>>>>>>>>> not working (in both tomcat 7.0.39 and 7.0.42), maybe >>>>>>>>>>> the two problems are related? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> I tried to reproduce with the information you >>>>>>>>>>>> provided so far, but I was unable. It works for me. >>>>>>>>>>> Also on my local machine, where jmx is not configured. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> Usually, a good place to look first, are the Tomcat logfiles. >>>>>>>>>> What do they say ? >>>>>>>>> searching for "java.lang.SecurityException: Restricted >>>>>>>>> (ContainerServlet) class >>>>>>>>> org.apache.catalina.manager.ManagerServlet" >>>>>>>> my HostManagerServlet is defined in >>>>>>>> webapps/host-manager/WEB-INF/web.xml as: >>>>>>>> HostManager >>>>>>>> >>>>>>>> org.apache.catalina.manager.host.HostManagerServlet >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> debug 2 >>>>>>>> >>>>>>>> HTMLHostManager >>>>>>>> >>>>>>>> org.apache.catalina.manager.host.HTMLHostManagerServlet >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>> >>>>>>>> debug 2 >>>>>>>> >>>>>>> the same for me. >>>>>>> >>>>>>> >>>>>>>>> seem that the solution is to add privileged="true" >>>>>>>> my privileged attr in Context is located at >>>>>>>> /webapps/host-manager/META-INF/context.xml as: >>>>>>> antiResourceLocking="false" privileged="true" /> >>>>>>> also this, the same. >>>>>>> >>>>>>> I can try with a new install (as suggested from Ognjen ) >>>>>>> >>>>>>> then try to use manager before install jsvc and befor setting >>>>>>> the jmx properties. >>>>>> Neither jsvc nor jmx should have any effect on what you are >>>>>> seeing. I would like to confirm that, however. Let us know what >>>>>> you discover. >>>>>> >>>>>> The SecurityException is certainly going to be a problem. It's >>>>>> odd that you saw the SecurityException which should fail to >>>>>> deploy the Manager, yet you are seeing the Manager's >>>>>> 404-not-found page which would require the Manager to be >>>>>> deployed. >>>>>> >>>>> The logfile says : >>>>> >>>>> Informazioni: Marking servlet Manager as unavailable ott 18, 2013 >>>>> 4:48:17 PM org.apache.catalina.core.StandardWrapperValve invoke >>>>> Grave: Allocate exception for servlet Manager >>>>> java.lang.SecurityException: Restricted (ContainerServlet) class >>>>> org.apache.catalina.manager.ManagerServlet >>>>> >>>>> So to my (admittedly untrained) eyes, it may look like the Manager >>>>> application (and its static pages) is deployed, but it is when >>>>> it's servlet is starting to run that the Java Security Manager >>>>> shoots it down.. It doesn't for that undeploy the whole app I >>>>> guess. >>>> >>>> Thanks for pointing that out; it makes much more sense given that >>>> explanation. >>>> >>> >>> I think that there was a clue quite a few messages ago : some parameter >>> in the Manager's web.xml had a value that probably meant that it wasn't >>> necesaarily initialised when Tomcat starts up, only when it is first >>> called. >> I didn't touch the manager application (at least not voluntarily!). >> >> >>> That may also explain why the latest logfile did not show any problem. >>> It was probably copied before the first real call to the Manager >>> happened. >> >>> Right now though, there is probably the same error message in the logs >>> as before, because Edoardo tried to call the Manager app, /after/ he >>> sent us the startup logfile. >> Are we talking of catalina.out? if so: no. the problem is that the >> exception log is not in catalina.out (or >> catalina-daemon.out in my system) but in manager.2013-10-18.log >> >> ott 18, 2013 6:44:14 PM org.apache.catalina.core.ApplicationContext log >> Informazioni: Marking servlet Manager as unavailable >> ott 18, 2013 6:44:14 PM org.apache.catalina.core.StandardWrapperValve >> invoke >> Grave: Allocate exception for servlet Manager >> java.lang.SecurityException: Restricted (ContainerServlet) class >> org.apache.catalina.manager.ManagerServlet >> at >> org.apache.catalina.core.DefaultInstanceManager.checkAccess(DefaultInstanceManager.java:538) >> >> at >> org.apache.catalina.core.DefaultInstanceManager.loadClassMaybePrivileged(DefaultInstanceManager.java:511) >> >> at >> org.apache.catalina.core.DefaultInstanceManager.newInstance(DefaultInstanceManager.java:137) >> >> at >> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1144) >> >> at >> org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:865) >> >> at >> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:136) >> >> at >> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) >> >> at >> org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:611) >> >> at >> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171) >> >> at >> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99) >> >> at >> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953) >> at >> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) >> >> at >> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408) >> >> at >> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023) >> >> at >> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589) >> >> at >> org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310) >> >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) >> >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) >> >> at java.lang.Thread.run(Thread.java:724) >> >> (the same as before) >> >> I am copying the whole Tomcat folder from the production server to my >> local virtual machine. >> >> >> I will post a detailed report (but it requests some time). >> >> > > To further clarify what Konstantin points to in his latest post : > > You should probably not do that (what you say above above "copying thw > whole Tomcat folder from the production server"). I copy the folder but I don't copy files from one installation to another, I need to be sure that I can reproduce the problem using my virtual linux installation. > What you should do, is make a clean Tomcat install, to some directory > where it was never installed before. > Then test the Manager app and JMX. > Then, item by item, bring in the webapps from your production server > into this clean installation. Do not overwrite files from the clean > installation by files from your production server. Instead, *modify* the > files of the clean installation this is my usual way! I use to copy only jmx files, and applications configuration. > > The reason, as Konstantin and others pointed out, is that on your > production server, things are probably quite messy by now, and you may > have several files which conflict with one another, invalid attributes > left over from older Tomcat versions etc. If you just copy every file > from the production server to your clean environment, you will copy the > mess also. believe me, surely there is something wrong but the modified files are very few! > So take your time, but do it nicely step by step, this is what I want to do. > About my wrong diagnosis of the Security Manager's implication : I also > did not see the parameters in the Java command-line which would have > started the Security Manager. But, being the occasional Java user which > I am, I kind of assumed that maybe the Security Manager might be started > by default in recent Java versions. > That was apparently a wrong assumption. > So anyway, Edoardo, forget what I wrote about catalina.policy. It is > not applicable here. I verified if some version ago (Tomcat 7.0.19) catalina.policy was different in some significat way. seems not. Edoardo --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org