Re: systemd tomcat script for Linux EL7
Firstly apologies to anyone I have sent an unsolicited reply to personally, Stupid, tired, It won't happen again Thanks to all for the responses so far The problem with using the startup and shutdown scripts is that the process ends up running as root. As any server admin worth his salt will tell you, running a 'public facing' service as root is a bad idea. The whole point of using jsvc is that you can start the container as root and switch to a non-privileged user later on. Thanks to those who have offered systemd type solutions, unfortunately none of them work on CentOS Linux release 7.2.1511. I now face the prospect of having to wade through the systemd docs and spend as much as needed experimenting to get this to work as required, still, I have nothing better to do ! Thanks again Lyallex On 17 March 2016 at 11:41, jieryn wrote: > ExecStartPre=/usr/sbin/setcap 'cap_net_bind_service=+ep' > /usr/share/tomcat/bin/catalina.sh > > I see a lot of advice for start/stop instead of run within systemd > unit files, both here and in the wild. The gem in the rant I linked is > about start vs run. Sorry if you didn't see it. > > On Thu, Mar 17, 2016 at 1:42 AM, Lyallex wrote: >> But that doesn't work for ports < 1024 >> >> >> On 17 March 2016 at 01:47, jieryn wrote: >>> Meh. It's short and sweet and working systemd unit file. >>> >>> [Unit] >>> Description=Apache Tomcat Web Application Container >>> [Service] >>> User=tomcat >>> Group=tomcat >>> ExecStart=/usr/share/tomcat/bin/catalina.sh run >>> [Install] >>> WantedBy=multi-user.target >>> >>> >>> On Wed, Mar 16, 2016 at 8:57 PM, Christopher Schultz >>> wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jieryn, On 3/16/16 1:36 PM, jieryn wrote: > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/systemd-house - -of-horror/tomcat.html Wow, > lots of ranting about environment variables and little-used PID files. If the author only understood the reasons behind the way catalina.sh works, he might not have embarrassed himself. It must be hard being so smart and important that you have to quit the Internet for good[1]. - -chris [1] http://homepage.ntlworld.com/jonathan.deboynepollard/contacting-the-auth or.html#SMTP > On Wed, Mar 16, 2016 at 1:01 PM, Lyallex > wrote: >> Apologies for dredging this up but I'm having some problems with >> this. Any ideas much appreciated. >> >> Ii have been forced to move from a version of centOS the used the >> old /etc/rc.d/init.d way of doing things to a new version of >> CentOS that uses systemd. The hosts can't or won't help because >> I'm using a 'non-standard setup' Basically I'm using tomcat >> standalone on port 80 to serve up my site. I use jsvc with a >> start/stop script in /etc/rc.d/init.d with symbolic links in >> rc2.d, rc3.d. rc4.d and rc5.d This has been working faultlessly >> for nearly 4 years. >> >> I have installed Tomcat, Java and all required resources on the >> new server, I have dulpicated the configuration in /etc but >> needless to say when I restart the server Tomcat doesn't start >> >> Starting from the command line as root with >> /etc/rc.d/init.d/tomcat7 works as it has always done and starts >> tomcat as root then switches to an unprivileged, no login user >> (tomcat) >> >> I followed your instructions and came up with the following >> >> # touch /etc/systemd/system/tomcat.service # nano >> /etc/systemd/system/tomcat.service >> >> tomcat.service looks like this >> >> [Unit] Description=The Jakarta Apache/Tomcat Server >> After=network.target >> >> [Service] Type=forking ExecStart=/etc/rc.d/init.d/tomcat7 start >> ExecStop=/etc/rc.d/init.d/tomcat7 stop >> >> [Install] WantedBy=multi-user.target >> >> # chmod 664 /etc/systemd/system/tomcat.service >> >> [root@vps init.d]# systemctl daemon-reload >> >> [root@vps init.d]# systemctl start tomcat.service Job for >> tomcat.service failed because the control process exited with >> error code. See "systemctl status tomcat.service" and "journalctl >> -xe" for details. >> >> [root@vps init.d]# systemctl status tomcat.service tomcat.service >> - The Jakarta Apache/Tomcat Server Loaded: loaded >> (/etc/systemd/system/tomcat.service; disabled; vendor preset: >> disabled) Active: failed (Result: exit-code) since Wed 2016-03-16 >> 16:40:55 GMT; 18s ago Process: 4596 >> ExecStart=/etc/rc.d/init.d/tomcat7 start (code=exited, >> status=203/EXEC) >> >> Mar 16 16:40:55 vps.example.com systemd[1]: Starting The Jakarta >> Apache/Tomcat Server... Mar 16 16:40:55 vps.example.com >> systemd[1]: tomcat.service: control process exited, code=exited >> status=203 Mar 16 16:40:55 vps.example.com systemd[1]: Fai
Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved
Would you mind posting your server.xml, here is the relevant bit from mine. On 18 March 2016 at 23:35, Daniel Savard wrote: > I believe all distros have over engineered the scripts to start > Tomcat. Forget all the scripts from your distro, learn the > signification of the environment variables from the catalina.sh script > shipped with the default Tomcat version. Define your variables in a > file, this file is not a script, so you cannot reuse a previously > defined variable, feed your systemd service definition file with this > file in the service section as EnvironmentFile=/path/name/to/your/file > ExecStart=/path/to/catalina.sh start > ExecStop=/path/to/catalina.sh stop > > and you are done. You control everything from the environment file, > you can easily manage the environment variables without editing the > systemd's service file. > > It is much simpler than the OpenRC set of scripts at my humble > opinion. I am running Gentoo at home and RHEL at work and both distros > wrapped Tomcat into too many layers of scripts in order to make it > working with OpenRC while none of these are required to run and manage > Tomcat with systemd. > > In particular with Gentoo, I no longer use the Tomcat distro packaged > with Gentoo because they separated the servlet api from Tomcat and you > need to wrap things into layers of scripts to define the classpath > properly taking this into account, the vanilla classpath.sh file > distributed with Tomcat doesn't work and so one. Really, they did a > very bad job at integrating Tomcat. > > Here is my service file: > > [Unit] > Description=Tomcat 8 (Dev) > After=syslog.target > After=network.target > > [Service] > EnvironmentFile=/tomcat/tomcat-8-dev/bin/tomcat-8-dev.env > Type=forking > User=tomcat > Group=tomcat > ExecStart=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh start > ExecStop=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh stop > > [Install] > WantedBy=multi-user.target > > > And here is the content of my EnvironmentFile: > > CATALINA_HOME="/opt/apache-tomcat/apache-tomcat-8.0.32_ds" > CATALINA_BASE="/tomcat/tomcat-8-dev" > CATALINA_OUT="/var/log/tomcat-8-dev/catalina.out" > JAVA_HOME="/opt/oracle-jdk-bin-1.8.0.74" > CATALINA_PID="/var/run/tomcat-8-dev.pid" > > > - > Daniel Savard > > > 2016-03-18 13:31 GMT-04:00 Lyallex : >> I thought you might be interested in the resolution to this. >> >> It turns out that we needed to reproduce the environment in tomcat.service >> >> For some reason >> >> ExecStart=/etc/rc.d/init.d/tomcat7 doesn't work >> (file shown at the end of this message) >> >> Instead, in /etc/systemd/system/tomcat.service >> we have had to reproduce the environment in longhand to get it to work. >> It appears that systemd doesn't expand variables so I really need to >> investigate the systemd Environment thing a bit more. >> Anyway, when I shutdown -r now the server comes back up and tomcat is >> running at the unprivileged tomcat user on port 80 so that's a result >> >> == /etc/systemd/system/tomcat.service >> [Unit] >> Description=Apache Tomcat Web Application Container >> After=network.target >> >> [Service] >> Type=forking >> User=root >> >> ExecStart=/opt/apache-tomcat-7.0.42/bin/jsvc \ >> -user tomcat \ >> -home /opt/jdk1.7.0_45 \ >> -Dcatalina.home=/opt/apache-tomcat-7.0.42 \ >> -Dcatalina.base=/opt/apache-tomcat-7.0.42 \ >> -Djava.io.tmpdir=/var/tmp \ >> -Djava.awt.headless=true \ >> -Xms512m \ >> -Xmx1024m \ >> -outfile /opt/apache-tomcat-7.0.42/logs/catalina.out \ >> -errfile /opt/apache-tomcat-7.0.42/logs/catalina.err \ >> -pidfile /var/run/tc7/jsvc.pid \ >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ >> -Djava.util.logging.config.file=/opt/apache-tomcat-7.0.42/conf/logging.properties >> \ >> -cp >> /opt/apache-tomcat-7.0.42/bin/bootstrap.jar:/opt/apache-tomcat-7.0.42/bin/commons-daemon.jar:/opt/jdk1.7.0_45/lib/tools.jar:/opt/apache-tomcat-7.0.42/bin/tomcat-juli.jar >> \ >> org.apache.catalina.startup.Bootstrap >> >> ExecStop=/bin/kill -9 /var/run/tc7/jsvc.pid >> ExecStopPost=/bin/rm -f /var/tc7lock/subsys/tomcat /var/run/tc7/jsvc.pid >> >> [Install] >> WantedBy=multi-user.target >> >> >> Oh happy day >> Thanks again to all responders >> >> Lyallex >> >> = /etc/rc.d/init.d/tomcat7 = >> >> JAVA_HOME=/opt/jdk1.7.0_45 >> CATALINA_HOME=/opt/apache-tomcat-7.0.42 >> export JAVA_HOME CATALINA_HOME >> CLASSPATH=$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons-daemon.jar:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/tomcat-juli.jar >> TOMCAT_USER=tomcat >> TMPDIR=/var/tmp >> PIDFILE=/var/run/tc7/jsvc.pid >> >> >> RC=0 >> >> case "$1" in >> >> start) >> >>$CATALINA_HOME/bin/jsvc -user $TOMCAT_USER -home $JAVA_HOME >> -Dcatalina.home=/opt/apache-tomcat-7.0.42 >> -Dcatalina.base=$CATALINA_HOME -Djava.io.tmpdir=$TMPDIR >> -Djava.awt.headless=true \ >>
Re: "Distinct and non-overlapping" context roots
On 17 March 2016 16:06:10 GMT+00:00, Paul Benedict wrote: >This question is not about Tomcat per se, but it does affect it. It's >really about the EE specification in regards to any servlet container. >I'd >like to get professional opinions on this part of the specification. > >I am quoting from EE 5.0 (see link below), section 8.3.1, paragraph 3c: > >The Deployer must... "Assign a context root for each web module >included in >the Java EE application. The context root is a relative name in the web >namespace for the application. Each web module must be given a distinct >and >non-overlapping name for its context root." > >So given this scenario: >/context/something <-- context is /context >/context/something/somethingelse <-- context is /context/something > >The specification puts no limitations on the context root character set >(so >it can include a slash). With that said, would you consider these >"overlapping" contexts? I noticed one application server supporting >this >paradigm without issue, but it seems like a violation of the >specification. >Please advise. > >Also, since Tomcat doesn't support "applications" (EAR?), how should >the >specification be interpreted in the absence of that artifact? > >[1] >http://download.oracle.com/otndocs/jcp/javaee-5.0-fr-eval-oth-JSpec/ > >Cheers, >Paul That requirement makes no sense as I understand it. You always have overlapping context paths because of the ROOT context. I think this is one for the EG to clarify what they meant. It is also worth noting that the servlet spec explicitly states thst requests are matched against the longest matching context path. Mark
Re: Memory and resources for Tomcat
On 3/17/2016 3:32 PM, Edwin Quijada wrote: > Hi! I am using Tomcat + APache +Postgres in the same machine server > with 8GB Ram I wanna know what is the best configuration memory or > anything else for better performance of my Tomcat? > > I have 400 user +- > > > My app is Grails + Vaadin +PostgreSQL > Memory for Grails: https://grails.org/wiki/FAQ Search for memory on the Wiki page. However, even for trivial applications it appears to consume 512 MB. Since you didn't say what version of Java you're running, it's hard to tell you what (if any) memory settings you'll need. Tomcat by itself uses very little memory Memory for Vaadin: https://vaadin.com/wiki/-/wiki/main/Scalable+web+applications There are several pieces of information concerning memory usage. Application memory in general: The above two links are for general information. The memory actually used is highly dependent on your application (see notes in the second link above). The best way to determine this is to measure (VisualVM, Java Mission Control, etc.). Memory for PostgreSQL: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server http://www.postgresql.org/docs/9.5/static/runtime-config-resource.html Again, this appears to be in part connection and schema dependent. Measurement is your only true option. In short, use the above links to get yourself into the ballpark. Then run your application under load and measure. Tomcat is probably the least resource-intensive component of your architecture. The above links are the result of less than 5 minutes of searching / skimming using Google. . . . just my two cents /mde/ signature.asc Description: OpenPGP digital signature
Re: Memory and resources for Tomcat
Thks, ! For postgres I dont have problem because I have xp with this but for Tomcat and Java and newbie with big projects . I am using Java 8 From: Mark Eggers Sent: Thursday, March 17, 2016 11:30 PM To: Tomcat Users List Subject: Re: Memory and resources for Tomcat On 3/17/2016 3:32 PM, Edwin Quijada wrote: > Hi! I am using Tomcat + APache +Postgres in the same machine server > with 8GB Ram I wanna know what is the best configuration memory or > anything else for better performance of my Tomcat? > > I have 400 user +- > > > My app is Grails + Vaadin +PostgreSQL > Memory for Grails: https://grails.org/wiki/FAQ Search for memory on the Wiki page. However, even for trivial applications it appears to consume 512 MB. Since you didn't say what version of Java you're running, it's hard to tell you what (if any) memory settings you'll need. Tomcat by itself uses very little memory Memory for Vaadin: https://vaadin.com/wiki/-/wiki/main/Scalable+web+applications There are several pieces of information concerning memory usage. Application memory in general: The above two links are for general information. The memory actually used is highly dependent on your application (see notes in the second link above). The best way to determine this is to measure (VisualVM, Java Mission Control, etc.). Memory for PostgreSQL: https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server http://www.postgresql.org/docs/9.5/static/runtime-config-resource.html Again, this appears to be in part connection and schema dependent. Measurement is your only true option. In short, use the above links to get yourself into the ballpark. Then run your application under load and measure. Tomcat is probably the least resource-intensive component of your architecture. The above links are the result of less than 5 minutes of searching / skimming using Google. . . . just my two cents /mde/ - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
contextDestroyed() method not called
Hi everyone, I noticed a problem with one of my web applications which requires some cleanup when shutdown. It seems this cleanup isn't happening even if everything has been put in the contextDestroyed() method of my web listener. So, to debug this problem I wrote a minimal web listener and tested to see what is going on. It seems the contextDestroyed() method isn't called when stopping the web application or stopping the Tomcat instance. Here is my minimal code: package some.thing; import javax.servlet.ServletContextEvent; import javax.servlet.ServletContextListener; import javax.servlet.annotation.WebListener; import org.apache.logging.log4j.LogManager; import org.apache.logging.log4j.Logger; @WebListener public class TestContext implements ServletContextListener { private Logger log = LogManager.getLogger(); public TestContext() { log.info("Constructor"); } @Override public void contextDestroyed(ServletContextEvent arg0) { log.info("Context destroyed."); } @Override public void contextInitialized(ServletContextEvent arg0) { log.info("Context initialized."); } } The constructor's info and the contextInitialized() info are both written to my log file, the info from the contextDestroyed() method is missing. I am running Tomcat 8.0.32 with Java 1.8.0.74, but I have seen a similar behavior with Tomcat 6.0.24 and Java 1.6.0.91 as well. I am using log4j 2.5. I find it difficult to believe this is a bug in Tomcat, so, I guess I am doing something wrong. Someone can provide some guidance to identify the cause of such undesirable behavior? Regards, - Daniel Savard - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Memory and resources for Tomcat
Hi! I am using Tomcat + APache +Postgres in the same machine server with 8GB Ram I wanna know what is the best configuration memory or anything else for better performance of my Tomcat? I have 400 user +- My app is Grails + Vaadin +PostgreSQL
Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved
Or remove the Type=Forking and just execute catalina.sh run, as I had suggested days ago. Then you can drop the ExecStop too. On Fri, Mar 18, 2016 at 7:35 PM, Daniel Savard wrote: > I believe all distros have over engineered the scripts to start > Tomcat. Forget all the scripts from your distro, learn the > signification of the environment variables from the catalina.sh script > shipped with the default Tomcat version. Define your variables in a > file, this file is not a script, so you cannot reuse a previously > defined variable, feed your systemd service definition file with this > file in the service section as EnvironmentFile=/path/name/to/your/file > ExecStart=/path/to/catalina.sh start > ExecStop=/path/to/catalina.sh stop > > and you are done. You control everything from the environment file, > you can easily manage the environment variables without editing the > systemd's service file. > > It is much simpler than the OpenRC set of scripts at my humble > opinion. I am running Gentoo at home and RHEL at work and both distros > wrapped Tomcat into too many layers of scripts in order to make it > working with OpenRC while none of these are required to run and manage > Tomcat with systemd. > > In particular with Gentoo, I no longer use the Tomcat distro packaged > with Gentoo because they separated the servlet api from Tomcat and you > need to wrap things into layers of scripts to define the classpath > properly taking this into account, the vanilla classpath.sh file > distributed with Tomcat doesn't work and so one. Really, they did a > very bad job at integrating Tomcat. > > Here is my service file: > > [Unit] > Description=Tomcat 8 (Dev) > After=syslog.target > After=network.target > > [Service] > EnvironmentFile=/tomcat/tomcat-8-dev/bin/tomcat-8-dev.env > Type=forking > User=tomcat > Group=tomcat > ExecStart=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh start > ExecStop=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh stop > > [Install] > WantedBy=multi-user.target > > > And here is the content of my EnvironmentFile: > > CATALINA_HOME="/opt/apache-tomcat/apache-tomcat-8.0.32_ds" > CATALINA_BASE="/tomcat/tomcat-8-dev" > CATALINA_OUT="/var/log/tomcat-8-dev/catalina.out" > JAVA_HOME="/opt/oracle-jdk-bin-1.8.0.74" > CATALINA_PID="/var/run/tomcat-8-dev.pid" > > > - > Daniel Savard > > > 2016-03-18 13:31 GMT-04:00 Lyallex : >> I thought you might be interested in the resolution to this. >> >> It turns out that we needed to reproduce the environment in tomcat.service >> >> For some reason >> >> ExecStart=/etc/rc.d/init.d/tomcat7 doesn't work >> (file shown at the end of this message) >> >> Instead, in /etc/systemd/system/tomcat.service >> we have had to reproduce the environment in longhand to get it to work. >> It appears that systemd doesn't expand variables so I really need to >> investigate the systemd Environment thing a bit more. >> Anyway, when I shutdown -r now the server comes back up and tomcat is >> running at the unprivileged tomcat user on port 80 so that's a result >> >> == /etc/systemd/system/tomcat.service >> [Unit] >> Description=Apache Tomcat Web Application Container >> After=network.target >> >> [Service] >> Type=forking >> User=root >> >> ExecStart=/opt/apache-tomcat-7.0.42/bin/jsvc \ >> -user tomcat \ >> -home /opt/jdk1.7.0_45 \ >> -Dcatalina.home=/opt/apache-tomcat-7.0.42 \ >> -Dcatalina.base=/opt/apache-tomcat-7.0.42 \ >> -Djava.io.tmpdir=/var/tmp \ >> -Djava.awt.headless=true \ >> -Xms512m \ >> -Xmx1024m \ >> -outfile /opt/apache-tomcat-7.0.42/logs/catalina.out \ >> -errfile /opt/apache-tomcat-7.0.42/logs/catalina.err \ >> -pidfile /var/run/tc7/jsvc.pid \ >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ >> -Djava.util.logging.config.file=/opt/apache-tomcat-7.0.42/conf/logging.properties >> \ >> -cp >> /opt/apache-tomcat-7.0.42/bin/bootstrap.jar:/opt/apache-tomcat-7.0.42/bin/commons-daemon.jar:/opt/jdk1.7.0_45/lib/tools.jar:/opt/apache-tomcat-7.0.42/bin/tomcat-juli.jar >> \ >> org.apache.catalina.startup.Bootstrap >> >> ExecStop=/bin/kill -9 /var/run/tc7/jsvc.pid >> ExecStopPost=/bin/rm -f /var/tc7lock/subsys/tomcat /var/run/tc7/jsvc.pid >> >> [Install] >> WantedBy=multi-user.target >> >> >> Oh happy day >> Thanks again to all responders >> >> Lyallex >> >> = /etc/rc.d/init.d/tomcat7 = >> >> JAVA_HOME=/opt/jdk1.7.0_45 >> CATALINA_HOME=/opt/apache-tomcat-7.0.42 >> export JAVA_HOME CATALINA_HOME >> CLASSPATH=$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons-daemon.jar:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/tomcat-juli.jar >> TOMCAT_USER=tomcat >> TMPDIR=/var/tmp >> PIDFILE=/var/run/tc7/jsvc.pid >> >> >> RC=0 >> >> case "$1" in >> >> start) >> >>$CATALINA_HOME/bin/jsvc -user $TOMCAT_USER -home $JAVA_HOME >> -Dcatalina.home=/opt/apache-tomcat-7.0.42 >> -Dcatalina.base=$CATALINA_HOME -Djava.io.tmpdir=$TMPDIR >> -Djava.awt.headless=true \ >> -Xms512m \ >>
Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved
I believe all distros have over engineered the scripts to start Tomcat. Forget all the scripts from your distro, learn the signification of the environment variables from the catalina.sh script shipped with the default Tomcat version. Define your variables in a file, this file is not a script, so you cannot reuse a previously defined variable, feed your systemd service definition file with this file in the service section as EnvironmentFile=/path/name/to/your/file ExecStart=/path/to/catalina.sh start ExecStop=/path/to/catalina.sh stop and you are done. You control everything from the environment file, you can easily manage the environment variables without editing the systemd's service file. It is much simpler than the OpenRC set of scripts at my humble opinion. I am running Gentoo at home and RHEL at work and both distros wrapped Tomcat into too many layers of scripts in order to make it working with OpenRC while none of these are required to run and manage Tomcat with systemd. In particular with Gentoo, I no longer use the Tomcat distro packaged with Gentoo because they separated the servlet api from Tomcat and you need to wrap things into layers of scripts to define the classpath properly taking this into account, the vanilla classpath.sh file distributed with Tomcat doesn't work and so one. Really, they did a very bad job at integrating Tomcat. Here is my service file: [Unit] Description=Tomcat 8 (Dev) After=syslog.target After=network.target [Service] EnvironmentFile=/tomcat/tomcat-8-dev/bin/tomcat-8-dev.env Type=forking User=tomcat Group=tomcat ExecStart=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh start ExecStop=/opt/apache-tomcat/apache-tomcat-8.0.32_ds/bin/catalina.sh stop [Install] WantedBy=multi-user.target And here is the content of my EnvironmentFile: CATALINA_HOME="/opt/apache-tomcat/apache-tomcat-8.0.32_ds" CATALINA_BASE="/tomcat/tomcat-8-dev" CATALINA_OUT="/var/log/tomcat-8-dev/catalina.out" JAVA_HOME="/opt/oracle-jdk-bin-1.8.0.74" CATALINA_PID="/var/run/tomcat-8-dev.pid" - Daniel Savard 2016-03-18 13:31 GMT-04:00 Lyallex : > I thought you might be interested in the resolution to this. > > It turns out that we needed to reproduce the environment in tomcat.service > > For some reason > > ExecStart=/etc/rc.d/init.d/tomcat7 doesn't work > (file shown at the end of this message) > > Instead, in /etc/systemd/system/tomcat.service > we have had to reproduce the environment in longhand to get it to work. > It appears that systemd doesn't expand variables so I really need to > investigate the systemd Environment thing a bit more. > Anyway, when I shutdown -r now the server comes back up and tomcat is > running at the unprivileged tomcat user on port 80 so that's a result > > == /etc/systemd/system/tomcat.service > [Unit] > Description=Apache Tomcat Web Application Container > After=network.target > > [Service] > Type=forking > User=root > > ExecStart=/opt/apache-tomcat-7.0.42/bin/jsvc \ > -user tomcat \ > -home /opt/jdk1.7.0_45 \ > -Dcatalina.home=/opt/apache-tomcat-7.0.42 \ > -Dcatalina.base=/opt/apache-tomcat-7.0.42 \ > -Djava.io.tmpdir=/var/tmp \ > -Djava.awt.headless=true \ > -Xms512m \ > -Xmx1024m \ > -outfile /opt/apache-tomcat-7.0.42/logs/catalina.out \ > -errfile /opt/apache-tomcat-7.0.42/logs/catalina.err \ > -pidfile /var/run/tc7/jsvc.pid \ > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ > -Djava.util.logging.config.file=/opt/apache-tomcat-7.0.42/conf/logging.properties > \ > -cp > /opt/apache-tomcat-7.0.42/bin/bootstrap.jar:/opt/apache-tomcat-7.0.42/bin/commons-daemon.jar:/opt/jdk1.7.0_45/lib/tools.jar:/opt/apache-tomcat-7.0.42/bin/tomcat-juli.jar > \ > org.apache.catalina.startup.Bootstrap > > ExecStop=/bin/kill -9 /var/run/tc7/jsvc.pid > ExecStopPost=/bin/rm -f /var/tc7lock/subsys/tomcat /var/run/tc7/jsvc.pid > > [Install] > WantedBy=multi-user.target > > > Oh happy day > Thanks again to all responders > > Lyallex > > = /etc/rc.d/init.d/tomcat7 = > > JAVA_HOME=/opt/jdk1.7.0_45 > CATALINA_HOME=/opt/apache-tomcat-7.0.42 > export JAVA_HOME CATALINA_HOME > CLASSPATH=$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons-daemon.jar:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/tomcat-juli.jar > TOMCAT_USER=tomcat > TMPDIR=/var/tmp > PIDFILE=/var/run/tc7/jsvc.pid > > > RC=0 > > case "$1" in > > start) > >$CATALINA_HOME/bin/jsvc -user $TOMCAT_USER -home $JAVA_HOME > -Dcatalina.home=/opt/apache-tomcat-7.0.42 > -Dcatalina.base=$CATALINA_HOME -Djava.io.tmpdir=$TMPDIR > -Djava.awt.headless=true \ > -Xms512m \ > -Xmx1024m \ > -outfile $CATALINA_HOME/logs/catalina.out \ > -errfile $CATALINA_HOME/logs/catalina.err \ > -pidfile '/var/run/tc7/jsvc.pid' \ > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager \ > -Djava.util.logging.config.file=$CATALINA_HOME/conf/logging.properties \ > -cp $CLASSPATH \ > org.apache.catalina.st
Re: systemd tomcat script for Linux EL7
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 jieryn, On 3/16/16 1:36 PM, jieryn wrote: > http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/systemd-house - -of-horror/tomcat.html Wow, > lots of ranting about environment variables and little-used PID files. If the author only understood the reasons behind the way catalina.sh works, he might not have embarrassed himself. It must be hard being so smart and important that you have to quit the Internet for good[1]. - -chris [1] http://homepage.ntlworld.com/jonathan.deboynepollard/contacting-the-auth or.html#SMTP > On Wed, Mar 16, 2016 at 1:01 PM, Lyallex > wrote: >> Apologies for dredging this up but I'm having some problems with >> this. Any ideas much appreciated. >> >> Ii have been forced to move from a version of centOS the used the >> old /etc/rc.d/init.d way of doing things to a new version of >> CentOS that uses systemd. The hosts can't or won't help because >> I'm using a 'non-standard setup' Basically I'm using tomcat >> standalone on port 80 to serve up my site. I use jsvc with a >> start/stop script in /etc/rc.d/init.d with symbolic links in >> rc2.d, rc3.d. rc4.d and rc5.d This has been working faultlessly >> for nearly 4 years. >> >> I have installed Tomcat, Java and all required resources on the >> new server, I have dulpicated the configuration in /etc but >> needless to say when I restart the server Tomcat doesn't start >> >> Starting from the command line as root with >> /etc/rc.d/init.d/tomcat7 works as it has always done and starts >> tomcat as root then switches to an unprivileged, no login user >> (tomcat) >> >> I followed your instructions and came up with the following >> >> # touch /etc/systemd/system/tomcat.service # nano >> /etc/systemd/system/tomcat.service >> >> tomcat.service looks like this >> >> [Unit] Description=The Jakarta Apache/Tomcat Server >> After=network.target >> >> [Service] Type=forking ExecStart=/etc/rc.d/init.d/tomcat7 start >> ExecStop=/etc/rc.d/init.d/tomcat7 stop >> >> [Install] WantedBy=multi-user.target >> >> # chmod 664 /etc/systemd/system/tomcat.service >> >> [root@vps init.d]# systemctl daemon-reload >> >> [root@vps init.d]# systemctl start tomcat.service Job for >> tomcat.service failed because the control process exited with >> error code. See "systemctl status tomcat.service" and "journalctl >> -xe" for details. >> >> [root@vps init.d]# systemctl status tomcat.service tomcat.service >> - The Jakarta Apache/Tomcat Server Loaded: loaded >> (/etc/systemd/system/tomcat.service; disabled; vendor preset: >> disabled) Active: failed (Result: exit-code) since Wed 2016-03-16 >> 16:40:55 GMT; 18s ago Process: 4596 >> ExecStart=/etc/rc.d/init.d/tomcat7 start (code=exited, >> status=203/EXEC) >> >> Mar 16 16:40:55 vps.example.com systemd[1]: Starting The Jakarta >> Apache/Tomcat Server... Mar 16 16:40:55 vps.example.com >> systemd[1]: tomcat.service: control process exited, code=exited >> status=203 Mar 16 16:40:55 vps.example.com systemd[1]: Failed to >> start The Jakarta Apache/Tomcat Server. Mar 16 16:40:55 >> vps.example.com systemd[1]: Unit tomcat.service entered failed >> state. Mar 16 16:40:55 vps.example.com systemd[1]: tomcat.service >> failed. >> >> tomcat7 fwiw >> >> >> # chkconfig: - 71 19 # description: Start up the Tomcat servlet >> engine. # this is the startup file for the new version # >> 24/10/2013 by lyallex # use java 7 # >> JAVA_HOME=/usr/local/java/jdk1.6.0_07 JAVA_HOME=/opt/jdk1.7.0_45 >> CATALINA_HOME=/opt/apache-tomcat-7.0.42 export JAVA_HOME >> CATALINA_HOME >> CLASSPATH=$CATALINA_HOME/bin/bootstrap.jar:$CATALINA_HOME/bin/commons - -daemon.jar:$JAVA_HOME/lib/tools.jar:$CATALINA_HOME/bin/tomcat-juli.jar >> >> TOMCAT_USER=tomcat >> TMPDIR=/var/tmp PIDFILE=/var/run/tc7/jsvc.pid >> >> >> RC=0 >> >> case "$1" in >> >> start) >> >> $CATALINA_HOME/bin/jsvc -user $TOMCAT_USER -home $JAVA_HOME >> -Dcatalina.home=/opt/apache-tomcat-7.0.42 >> -Dcatalina.base=$CATALINA_HOME -Djava.io.tmpdir=$TMPDIR >> -Djava.awt.headless=true \ -Xms512m \ -Xmx1024m \ -outfile >> $CATALINA_HOME/logs/catalina.out \ -errfile >> $CATALINA_HOME/logs/catalina.err \ -pidfile >> '/var/run/tc7/jsvc.pid' \ >> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager >> \ >> -Djava.util.logging.config.file=$CATALINA_HOME/conf/logging.propertie s >> \ -cp $CLASSPATH \ org.apache.catalina.startup.Bootstrap >> >> RC=$? >> >> [ $RC = 0 ] && touch /var/tc7lock/subsys/tomcat echo "starting >> tomcat7 on darkstar with:" echo "JAVA_HOME=$JAVA_HOME" echo >> "CATALINA_HOME=$CATALINA_HOME" echo "CLASSPATH=$CLASSPATH" echo >> "tomcat started" >> >> echo "CLASSPATH=$CLASSPATH" echo "tomcat started" ;; >> >> stop) >> >> PID=`cat /var/run/tc7/jsvc.pid` kill $PID >> >> RC=$? >> >> [ $RC = 0 ] && rm -f /var/tc7lock/subsys/tomcat >> /var/run/tc7/jsvc.pid echo "stopping tomcat7 on darkstar with:" >> echo "JAVA_HOME=$JAVA_HOME" echo "CATALINA_HOME=$CATALINA_HOME" >> echo "CLASSPATH
Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build
On 15/03/2016 20:58, Harish Krishnan wrote: > Hello There, > > I am kind of blocked here in my project while applying your CVE fix in our > product & verify the fix. Any guidelines on what i am doing (mentioned in > my previous email) wrong is highly appreciated. You are failing to follow the hints you have been given previously. > All i am trying to do is, disable the redirect for the root (Ex: /manager & > /examples in tomcat) of the webapp. If i know how to do this on the > mentioned tomcat webapps, then i can apply the same for my webapps too. > Looking for your response & help here. You CAN NOT disable the redirect. As the documentation for the two redirect options makes clear, all they do is change WHERE the redirect happens. The key point in all of this is that security constraints are applied AFTER the Mapper and BEFORE the DefaultServlet. If the request is for a protected resource and the redirects take place in the Mapper, then the response will confirm whether that resource exists irrespective of whether or not the user is authorized to access the resource. If the redirect takes place in the Default Servlet, the response will reflect the security constraints and the user's access rights if any. Again, you need to look at the security constraints for the Manager application. /manager is NOT a protected resource so the redirect is always going to happen. Mark > > > regards > Harish Krishnan > > On Fri, Mar 11, 2016 at 4:05 PM, Harish Krishnan > wrote: > >> Thanks again for the reply, Chris & Violeta! >> Thanks for clarifying what the "protected directory" is, even i guessed it >> to be same. Now i understood the fix for the directories protected by a >> security constraint. I also verified this & the redirect is no more >> happening for these protected ones. Really appreciate your help here. >> >> However, i am still unable to disable the redirect for the root of the >> webapp. This is what i did on the latest tomcat build (7.0.68) - >> >> a) Set the context attribute (mapperContextRootRedirectEnabled) to false >> for manager webapp. Here is my context.xml (from >> \webapps\manager\META-INF\) file - >> >> > antiResourceLocking="false" privileged="true" > >> >> >> b) Accessing http://localhost:8080/manager gets redirected to manger/. >> >> c) I have also set the above context attribute in the default context.xml >> (from \conf\context.xml) file as well. >> >> d) Accessing http://localhost:8080/examples gets redirected to examples/. >> >> Not sure what i am missing here. Same behavior is seen on my web >> application too. >> Please let me know where i am doing wrong & help me on how to disable the >> redirect for the root of webapps. >> >> >> regards >> Harish Krishnan >> >> >> >> >> >> >> >> On Wed, Mar 9, 2016 at 7:29 AM, Christopher Schultz < >> ch...@christopherschultz.net> wrote: >> >>> Harish, >>> >>> On 3/8/16 5:47 PM, Harish Krishnan wrote: Thanks Chris for the reply. Looks like my understanding of the fix is incorrect. I assumed (my bad) that, with the fix for this CVE in place (tomcat 7.0.68) + setting the additional context attribute (mapperContextRootRedirectEnabled="false"), all the redirects for that webapp where context attribute was set, will completely be disabled. You mentioned that only "protected directories" inside the deployed web application is covered in this CVE fix. Can you please help me understand what this protected directories are & >>> how to configure this in tomcat ? >>> >>> A "protected directory" is one that has a in >>> web.xml. That's not a spec-defined term... just one we've been using >>> because it captures the meaning with fewer words. >>> >>> As for the redirects you are seeing that "expose" the availability of a >>> particular web application, those are essentially impossible to prevent, >>> and not considered a part of the CVE. >>> >>> -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: contextDestroyed() method not called
Nevermind, the contextDestroyed() method is actually called as supposed and expected. The problem seems the logger is no longer able to output anything in the log file at this point even if I configured it to flush immediately the output. I replaced the log.info() statement by a System.out.println() followed by a System.out.flush() and I can see the output. However, it seems the context is destroyed before my objects are themselves destroyed since I still receive messages in the catalina.out about them, like this one: INFOS: Closing Spring root WebApplicationContext Destruction du contexte applicatif. Application: CaissesDispo, Serveur: Apache Tomcat/8.0.32_ds Désinscrit les écouteurs de requêtes uCMDB. Détruit le bassin de connexions uCMDB. Application: CaissesDispo terminée. mars 17, 2016 7:44:15 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads AVERTISSEMENT: The web application [CaissesDispo] appears to have started a thread named [UCMDB Model Notifications Service Notification Thread] but has failed to stop it. This is very likely to create a memory leak. Stack trace of thread: sun.misc.Unsafe.park(Native Method) java.util.concurrent.locks.LockSupport.park(LockSupport.java:175) java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039) java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442) com.hp.ucmdb.api.client.topology.notification.AbstractNotificationService$NotifyListeners.run(AbstractNotificationService.java:244) java.lang.Thread.run(Thread.java:745) mars 17, 2016 7:44:15 PM org.apache.catalina.loader.WebappClassLoaderBase clearReferencesThreads Anything can be done to avoid these messages if the objects are actually destroyed? - Daniel Savard 2016-03-17 19:08 GMT-04:00 Daniel Savard : > From the manager clicking on the Stop button for the application. For > the instance, on Windows just stop the Tomcat service, on Linux, just > run the catalina.sh stop script. > - > Daniel Savard > > > 2016-03-17 8:47 GMT-04:00 Caldarale, Charles R : >>> From: Daniel Savard [mailto:daniel.sav...@gmail.com] >>> Subject: Re: contextDestroyed() method not called >> >> Read the mailing list rules: don't top post. >> http://tomcat.apache.org/lists.html#tomcat-users >> >>> I'm running it on Window 2012 Server as well as Linux RHEL. >> >> Ok, good to know. >> >>> And no, I am not sending a terminate signal with kill -9. That's why I >>> said I am stopping the application or the instance (both cases depict >>> the same behavior) rather than saying I am terminating it. >> >> Again, how are you doing this? >> >> - Chuck >> >> >> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY >> MATERIAL and is thus for use only by the intended recipient. If you received >> this in error, please contact the sender and delete the e-mail and its >> attachments from all computers. >> >> >> - >> 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: Tomcat 8 Hung State
On 18/03/2016 15:06, Theo Sweeny wrote: > Hi Mark, > hanks for the reply - the developers are pushing back as they believe Tomcat > should kill off any rogue webapps after a certain timeframe as this is how > they have it done in Weblogic. I believe WebLogic runs each web application in a separate JVM (or at least provides an option to do so). That allows developers to get away with all sorts of poor practice because the container can simply kill the JVM to clean things up. Tomcat doesn't work like that. In Tomcat all web applications are hosted in a single JVM. Java provides no safe mechanism for stopping a currently processing thread. Therefore there is very little / nothing Tomcat can do. The developers need to fix their broken code. > When I do an Strace on a broken webapp, the following can be seen - > > 11297 11:39:23.023838 write(105, "2016-03-18 11:39:23,021 138066033 > [http-nio-10080-exec-27] ERROR > com.spring.business.service.security.ldap.filter.CustomAuthFilter - > Exception thrown in doFilterInternal: > {}\norg.apache.catalina.connector.ClientAbortException: java.io.IOException: > Broken pipe\n\tat > org.apache.catalina.connector.OutputBuffer.realWriteBytes(OutputBuffer.java:393) > ~[catalina.jar:8.0.21]\n\tat > org.apache.tomcat.util.buf.ByteChunk.flushBuffer(ByteChunk.java:426) > ~[tomcat-util.jar:8.0.21]\n\tat org.apache.catalina.connector."..., 17236 > > > Is this due to Tomcat's inability to recover from a lost datasource? That looks like a client dropping the connection. Tomcat will handle that happily. Whether the app does is a different question. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org