Re: systemd tomcat script for Linux EL7

2016-03-18 Thread Lyallex 
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]:

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

2016-03-18 Thread Lyallex 
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

Re: "Distinct and non-overlapping" context roots

2016-03-18 Thread Mark Thomas 
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

2016-03-18 Thread Mark Eggers 
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

2016-03-18 Thread Edwin Quijada 
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

2016-03-18 Thread Daniel Savard 
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

2016-03-18 Thread Edwin Quijada 
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

2016-03-18 Thread jieryn 
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
>>

Re: porting jsvc startup script from init.d to systemd tomcat.service, resolved

2016-03-18 Thread Daniel Savard 
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  \
>

Re: systemd tomcat script for Linux EL7

2016-03-18 Thread Christopher Schultz 
-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"

Re: Question about your recent security (CVE-2015-5345) fix in 7.0.68 build

2016-03-18 Thread Mark Thomas 
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

2016-03-18 Thread Daniel Savard 
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

2016-03-18 Thread Mark Thomas 
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