RE: Packet misses in Tomcat
-Original Message- From: Stefan Mayr [mailto:ste...@mayr-stefan.de] Sent: 13 January 2014 23:26 To: users@tomcat.apache.org Subject: Re: Packet misses in Tomcat Am 13.01.2014 07:22, schrieb Divyaprakash Y: > -Original Message- > From: Stefan Mayr [mailto:ste...@mayr-stefan.de] > Sent: 10 January 2014 23:26 > To: users@tomcat.apache.org > Subject: Re: Packet misses in Tomcat > > Hi > > Am 09.01.2014 14:21, schrieb Divyaprakash Y: >> >> >> -Original Message- >> From: Divyaprakash Y >> Sent: 08 January 2014 14:35 >> To: Tomcat Users List >> Subject: RE: Packet misses in Tomcat >> > ... >> Strange that this is happening only to me. > Looks like something similar was reported on the dev list when voting for > Tomcat 7.0.50 .. >> Thanks. >>> >> >> I tried same setup today with the BIO connector, everything worked >> flawlessly. Will there be any issue with the APR connector(earlier setup) or >> are there any extra configurations which I missed in my server.xml? > > This might be the issue seen in > https://issues.apache.org/bugzilla/show_bug.cgi?id=55976 . Looks like > Mark fixed it today for 7.0.51 (not released yet) > > - Stefan >> >> > > Thanks Stefan for the information. > > Should that(Fix on NIO Connector) fix the possible issue in APR Connector as > well? I guess not. But maybe you shoudl 7.0.50 give a try. APR was updated in one of the not released versions after your lastest 7.0.42. Also a minimal testcase would help to check if this is reproducable on other peoples machine (like they did in the bugzilla ticket) - Stefan > Thanks Stefan, will definitely try "Tomcat 7.0.50" as well as try to build a minimal test case.. - DISCLAIMER: This electronic message and any attachments to this electronic message is intended for the exclusive use of the addressee(s) named herein and may contain legally privileged and confidential information. It is the property of Celstream Systems Private Limited. If you are not the intended recipient, you are hereby strictly notified not to copy, forward, distribute or use this message or any attachments thereto. If you have received this message in error, please delete it and all copies thereof, from your system and notify the sender at Celstream Systems or administrat...@celstream.com immediately. -
Re: jasper2 doesn't support the "validateXml" attribute
2014/1/15 Mark Thomas
> Gernot wrote:
> >Hi,
> >
> >I did an upgrade from tomcat 7.0.29 to 7.0.50.
> >In 7.0.50 jasper2 ant task quits with error 'jasper2 doesn't support
> >the
> >"validateXml" attribute'
> >
> >Here's the mentioned code:
> > > uriroot="${build}"
> > webXmlFragment="${build}/WEB-INF/generated_web.xml"
> > addWebXmlMappings="true"
> > outputDir="${build}/WEB-INF/classes"
> > compilerSourceVM="7.0"
> > compilerTargetVM="7.0" />
> >
> >
> >I havn't found any information about this in tomcat's changelog.
> >Is this a bug? Or a feature?
> >What's the suggested way to handle this error?
> >
> >Thanks
>
> It got renamed to validateTld to better describe what it actually does as
> part of the XML work in 7.0.48 (which wasn't released until 7.0.50). I see
> at least one place in the docs where this wasn't changed. I'll get that
> fixed for the next release. If this turns out to be a problem for folks we
> can add support for the old name as well.
>
> Mark
>
In my opinion it's not a good idea to break api in minor version upgrade.
And why isn't there any comment in the changelog?
Please document changes in the changelog!
Gernot
Re: tomcat 7 with APR connector on ubuntu
Hi, See interleaved. On 15 January 2014 16:53, Mubeen Shah wrote: > Hello, > > I am trying to configure tomcat 7 on ubuntu machine and wanted to run it as > non-root on port 80, Here is what I did so far: > > OS (Ubuntu 12.04 LTS): > > - installed oracle JDK 1.7.0_45 using "apt-get" > - downloaded and extracted tomcat 7.0.50 (.gz format) > - created ubuntu user 'tomcat' and granted 'chown -R CATALINA_HOME' to this > user > - changed tomcat default port to 80 in server.xml > - installed and configured authbind tool > - created sh script "/etc/init.d/tomcat7" to start tomcat as tomcat user. > What was in this script? > - tomcat 7 was working as expected on 80 port as non-root user. > That is surprising, see further below. > - later I configured APR 1.5.0 and tried to run tomcat again, I got this > error: > > Jan 15, 2014 6:24:45 AM org.apache.catalina.core.AprLifecycleListener init > INFO: Loaded APR based Apache Tomcat Native library 1.1.29 using APR > version 1.5.0. > Jan 15, 2014 6:24:45 AM org.apache.catalina.core.AprLifecycleListener init > INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters > [false], random [true]. > Jan 15, 2014 6:24:46 AM org.apache.catalina.core.AprLifecycleListener > initializeSSL > INFO: OpenSSL successfully initialized (OpenSSL 1.0.1 14 Mar 2012) > Jan 15, 2014 6:24:46 AM org.apache.coyote.AbstractProtocol init > INFO: Initializing ProtocolHandler ["http-apr-80"] > Jan 15, 2014 6:24:46 AM org.apache.coyote.AbstractProtocol init > SEVERE: Failed to initialize end point associated with ProtocolHandler > ["http-apr-80"] > java.lang.Exception: Socket bind failed: [13] Permission denied > at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:430) > at > org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:640) > at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:434) > at > org.apache.catalina.connector.Connector.initInternal(Connector.java:981) > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) > at > org.apache.catalina.core.StandardService.initInternal(StandardService.java:559) > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) > at > org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814) > at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) > at org.apache.catalina.startup.Catalina.load(Catalina.java:639) > at org.apache.catalina.startup.Catalina.load(Catalina.java:664) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) > This is expected. > > If I am removing out this line from server.xml: > SSLEngine="on" /> > > Tomcat working on 80 port as non-root user and starting "http-bio-80" > properly. > > Another thing is if I am trying to run tomcat as "root" along with APR > support, its working just fine. > > Any advise why its working on "http-bio-80" while throwing bind exception > on "http-apr-80"?? > Linux will not allow anything but root to bind on ports < 1024. Usually the process starts as root, binds to the port and then drops it's privileges back to the desired user. You'll need to use jsvc to start Tomcat and drop privileges. It is simply apache commons daemon and you should use version 1.0.15 or higher, I'm not sure what version is in 12.04 LTS so you may need to compile it. Some documentation is here: http://tomcat.apache.org/tomcat-7.0-doc/setup.html http://commons.apache.org/proper/commons-daemon/jsvc.html There are a couple of other options described here: http://wiki.apache.org/tomcat/HowTo#How_to_run_Tomcat_without_root_privileges.3F But the best one is commons daemon / jsvc. > Regards, > Mubeen > -- Kind regards, Brett
Re: Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.
On 1/15/2014 10:13 AM, Тимур Кулибаев wrote: > Hello, Chris ! > > I applied settings you adviced: > Don't you want user.langauge=RU user.country=kz? > > [oracle@n36 logs]$ echo $JAVA_OPTS > -XX:MaxPermSize=128M -Xms256m -Xmx1024m -Duser.language=RU -Duser.country=kz > > But our java-application gives the following message: > > 15.01.2014 21:41:01 org.apache.catalina.core.ApplicationContext log > MESSAGE = ORA-00604: error occurred at recursive SQL level 1 > ORA-12705: invalid or unknown NLS parameter value specified > , ERRORCODE = 604 > > So, there can be problems in a couple of places. If you have an > extended characters correctly-stored in the Oracle database, will it > display correctly if you try to show it on a web page? Let's make sure > that works first, then we'll tackle submitting such characters via > forms. > Note that using extended characters in GET requests is a nightmare: > you should try to avoid it at all costs. > > There are two state languages in Kazakhstan - Russian and Kazakh and both > must > be supported. Our Oracle database works in single-byte cyrillic encoding > and > its size is up to 1 tB now. If we convert one to Unicode it will be ~2 tB > which > is impossible for us as no disk space. > Our java servlet was created based on Oracle UIX technology which is old > enough. > Within seven years we successfully use this servlet with Oracle Application > Server 10g R2/R3 (now OAS 10.1.3.5). There are not any troubles with Kazakh > letters displaying on web-pages with Oracle Application Server. But Tomcat > gives > troubles with Kazakh letters displaying. What difference between Oracle > Application > Server and Tomcat in characters processing ? In production we still use > this > servlet with Oracle Application Server. I can see any its settings if you > tell me > which ones to check. > >From Tomcat doc I see that we can convert GET-request to specified code > page by > using "URIEncoding" in http-connector definition of server.xml. I have > tried to use > the followng: > connectionTimeout="2" > redirectPort="8443" > URIEncoding="Cp1251" <-- also tried Windows-1251, WINDOWS-1251, CP1251 > useBodyEncodingForURI="true"/> <--also tried without this one > > May be we must do some tracing to understand the root of the trouble ? > > Thank you for your helping me. > Waiting for your advices, > Timur Hi, Timur- I've missed a good part of this thread but is the content type set either with the page directive or HttpServletResponse.setContentType()? -Terence Bandoian - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
Comments inline: On 1/15/2014 9:46 AM, Bush, Eddie wrote: Great feedback, Mark! Thanks! As this will be for a single app, I'm not concerned with having quite as complex of a setup as you do. The box does not seem to have selinux enabled: [ebush@tuldgskap01 ~]$ selinuxenabled [ebush@tuldgskap01 ~]$ echo $? 1 Not enabled. I think this is probably not wise (especially in production machines). We run with selinux enforcing on production and permissive on development boxes. Is there something that would cause the script to be successfully invocable interactively and yet make it fail at boot? I'm thinking the answer is yes, based off of what I'm seeing. Perhaps sudo doesn't like being run by root? Don't use sudo in a script. If you're running selinux use: /sbin/runuser [user-name] -c [command] If you're not running selinux use: /sbin/su [user-name] -c [command] Since I'll lead the dev team, I'll have teeth to make sure the app does not misbehave. I can't imagine why one would, as I've never had issues before. I suppose, if requests were still processing, a problem could occur. However, we'll use F5 and drain-stop the node prior to performing maintenance, so ... I'm going to take a simpler path than you've advocated but keep your thoughts around in case I do experience an issue :-) I'll look into a more formal daemon mechanism. I think commons-daemon comes with tomcat. I'm trying to avoid many manual pieces like that, but working (and I define working as "it comes up after boot") is not optional! Yes, it does come with Tomcat. However your script should work (wouldn't recommend it for production, but dev would be OK) provided you use /sbin/su or /sbin/runuser. Thanks again! ... and thanks to the others who have provided feedback too! It is very much appreciated! My take-away: there's a standard way to launch a daemon, and you should be doing that! Eddie . . . . just my two cents /mde/ -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Wednesday, January 15, 2014 11:24 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot See quick notes next to your script: On 1/15/2014 8:53 AM, Bush, Eddie wrote: -Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Wednesday, January 15, 2014 10:19 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot On Jan 15, 2014, at 11:01 AM, "Bush, Eddie" wrote: -Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Wednesday, January 15, 2014 9:54 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: Howdy, List! I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but for my new client I'm also charged with configuring our machines. We're running on Tomcat 7, so I grabbed the tgz and installed it per the instructions. Everything works great! ... until I reboot the server :) At that point, everything else comes up, but tomcat does not. I have removed all logs and rebooted and see nothing notable in any of the tomcat logs (because, of course, it did not start), nor can I find anything in syslog or messages. The chkconfig command reports that the script is configured to run for runlevel 2-5, and I've even inspected the links in rc.d/rc*.d and they are linked to the init.d script (which is the same danged script that works interactively via "service tomcat start/stop"!) Dan> Where did you get the init script from? EB> Off the net somewhere, initially. I tweaked it to use sudo to EB> change user to tomcat:tomcat though, and I changed the chkconfig EB> declaration to be extremely similar to what nginx uses, since EB> that works fine. chkconfig likes the script, and sets it up in EB> what looks to be perfect form (comparing to other things). These EB> are pretty standard scripts though, yes? They basically just EB> delegate to the scripts distributed with tomcat, which all end up EB> calling catalina.sh :-) Dan> Since it's not standard, can you include it here? It may be perfectly fine, but it would be nice to see it regardless. EB> cat /etc/init.d/tomcat #!/bin/bash echo "Let's start Tomcat! ... because Tomcat rocks!" > /tmp/tomcat.log # chkconfig: - 84 16 # description: Tomcat Start Stop Restart # processname: tomcat ### BEGIN INIT INFO # Provides: tomcat # Required-Start: $local_fs $remote_fs $network # Required-Stop: $local_fs $remote_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start stop and restart tomcat ### END INIT INFO JAVA_HOME=/usr/java/jdk1.7.0_45 export JAVA_HOME PATH=$JAVA_HOME/bin:$PATH export PATH CATALINA_HOME=/usr/share/apache-tomcat-7.0.47 echo "JAVA_HOME = $JAVA_HOME" >> /tmp/tomcat.log echo "PATH = $PATH" /tmp/tomcat.log echo "CATALINA_HOME = $CATALINA_HOME
RE: [tomcat7] rhel 6 - init.d script works; does not start on reboot
On 1/15/2014 11:46 AM, Bush, Eddie wrote:
> Great feedback, Mark! Thanks!
>
> As this will be for a single app, I'm not concerned with having quite as
> complex of a setup as you do. The box does not seem to have selinux enabled:
>
> [ebush@tuldgskap01 ~]$ selinuxenabled
> [ebush@tuldgskap01 ~]$ echo $?
> 1
>
> Is there something that would cause the script to be successfully invocable
> interactively and yet make it fail at boot? I'm thinking the answer is yes,
> based off of what I'm seeing. Perhaps sudo doesn't like being run by root?
>
> Since I'll lead the dev team, I'll have teeth to make sure the app does not
> misbehave. I can't imagine why one would, as I've never had issues before. I
> suppose, if requests were still processing, a problem could occur. However,
> we'll use F5 and drain-stop the node prior to performing maintenance, so ...
> I'm going to take a simpler path than you've advocated but keep your thoughts
> around in case I do experience an issue :-)
>
> I'll look into a more formal daemon mechanism. I think commons-daemon comes
> with tomcat. I'm trying to avoid many manual pieces like that, but working
> (and I define working as "it comes up after boot") is not optional!
>
> Thanks again! ... and thanks to the others who have provided feedback too! It
> is very much appreciated! My take-away: there's a standard way to launch a
> daemon, and you should be doing that!
>
> Eddie
>
Hi, Eddie-
It's been a while but one script I used had the following start line:
daemon --user ${tomcat_user} ${tomcat_script} start ${tomcat_start_opts}
where daemon was a function defined in init.d/functions. Within daemon,
runuser was used to execute the startup script.
-Terence Bandoian
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
RE: [tomcat7] rhel 6 - init.d script works; does not start on reboot
Great feedback, Mark! Thanks! As this will be for a single app, I'm not concerned with having quite as complex of a setup as you do. The box does not seem to have selinux enabled: [ebush@tuldgskap01 ~]$ selinuxenabled [ebush@tuldgskap01 ~]$ echo $? 1 Is there something that would cause the script to be successfully invocable interactively and yet make it fail at boot? I'm thinking the answer is yes, based off of what I'm seeing. Perhaps sudo doesn't like being run by root? Since I'll lead the dev team, I'll have teeth to make sure the app does not misbehave. I can't imagine why one would, as I've never had issues before. I suppose, if requests were still processing, a problem could occur. However, we'll use F5 and drain-stop the node prior to performing maintenance, so ... I'm going to take a simpler path than you've advocated but keep your thoughts around in case I do experience an issue :-) I'll look into a more formal daemon mechanism. I think commons-daemon comes with tomcat. I'm trying to avoid many manual pieces like that, but working (and I define working as "it comes up after boot") is not optional! Thanks again! ... and thanks to the others who have provided feedback too! It is very much appreciated! My take-away: there's a standard way to launch a daemon, and you should be doing that! Eddie -Original Message- From: Mark Eggers [mailto:its_toas...@yahoo.com] Sent: Wednesday, January 15, 2014 11:24 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot See quick notes next to your script: On 1/15/2014 8:53 AM, Bush, Eddie wrote: > > > -Original Message- > From: Daniel Mikusa [mailto:dmik...@gopivotal.com] > Sent: Wednesday, January 15, 2014 10:19 AM > To: Tomcat Users List > Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on > reboot > > On Jan 15, 2014, at 11:01 AM, "Bush, Eddie" wrote: > >> >> >> -Original Message- >> From: Daniel Mikusa [mailto:dmik...@gopivotal.com] >> Sent: Wednesday, January 15, 2014 9:54 AM >> To: Tomcat Users List >> Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start >> on reboot >> >> On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: >> >>> Howdy, List! >>> >>> I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, >>> but for my new client I'm also charged with configuring our machines. We're >>> running on Tomcat 7, so I grabbed the tgz and installed it per the >>> instructions. >>> >>> Everything works great! ... until I reboot the server :) At that point, >>> everything else comes up, but tomcat does not. >>> >>> I have removed all logs and rebooted and see nothing notable in any >>> of the tomcat logs (because, of course, it did not start), nor can I >>> find anything in syslog or messages. The chkconfig command reports >>> that the script is configured to run for runlevel 2-5, and I've even >>> inspected the links in rc.d/rc*.d and they are linked to the init.d >>> script (which is the same danged script that works interactively via >>> "service tomcat start/stop"!) >> >> Dan> Where did you get the init script from? >> EB> Off the net somewhere, initially. I tweaked it to use sudo to >> EB> change user to tomcat:tomcat though, and I changed the chkconfig >> EB> declaration to be extremely similar to what nginx uses, since >> EB> that works fine. chkconfig likes the script, and sets it up in >> EB> what looks to be perfect form (comparing to other things). These >> EB> are pretty standard scripts though, yes? They basically just >> EB> delegate to the scripts distributed with tomcat, which all end up >> EB> calling catalina.sh :-) > > Dan> Since it's not standard, can you include it here? It may be perfectly > fine, but it would be nice to see it regardless. > EB> cat /etc/init.d/tomcat > #!/bin/bash > > echo "Let's start Tomcat! ... because Tomcat rocks!" > /tmp/tomcat.log > > # chkconfig: - 84 16 > # description: Tomcat Start Stop Restart # processname: tomcat > > ### BEGIN INIT INFO > # Provides: tomcat > # Required-Start: $local_fs $remote_fs $network # Required-Stop: > $local_fs $remote_fs $network # Default-Start: 2 3 4 5 # Default-Stop: > 0 1 6 # Short-Description: start stop and restart tomcat ### END INIT > INFO > > JAVA_HOME=/usr/java/jdk1.7.0_45 > export JAVA_HOME > PATH=$JAVA_HOME/bin:$PATH > export PATH > CATALINA_HOME=/usr/share/apache-tomcat-7.0.47 > > echo "JAVA_HOME = $JAVA_HOME" >> /tmp/tomcat.log echo "PATH = $PATH" > >> /tmp/tomcat.log echo "CATALINA_HOME = $CATALINA_HOME" >> > /tmp/tomcat.log > > case $1 in > start) > echo "START requested!" >> /tmp/tomcat.log sudo -g tomcat -u tomcat sh > $CATALINA_HOME/bin/startup.sh ;; > stop) > echo "STOP requested!" >> /tmp/tomcat.log sudo -g tomcat -u tomcat sh > $CATALINA_HOME/bin/shutdown.sh ;; > restart) > echo "RESTART requested!" >> /tmp/tomcat.log sudo -g tomcat -u tomcat > sh $CATALINA_HOME/bin/shutdown.sh sudo -g tomcat -
Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
See quick notes next to your script:
On 1/15/2014 8:53 AM, Bush, Eddie wrote:
-Original Message-
From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
Sent: Wednesday, January 15, 2014 10:19 AM
To: Tomcat Users List
Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
On Jan 15, 2014, at 11:01 AM, "Bush, Eddie" wrote:
-Original Message-
From: Daniel Mikusa [mailto:dmik...@gopivotal.com]
Sent: Wednesday, January 15, 2014 9:54 AM
To: Tomcat Users List
Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote:
Howdy, List!
I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but
for my new client I'm also charged with configuring our machines. We're running
on Tomcat 7, so I grabbed the tgz and installed it per the instructions.
Everything works great! ... until I reboot the server :) At that point,
everything else comes up, but tomcat does not.
I have removed all logs and rebooted and see nothing notable in any of the tomcat logs
(because, of course, it did not start), nor can I find anything in syslog or messages.
The chkconfig command reports that the script is configured to run for runlevel 2-5, and
I've even inspected the links in rc.d/rc*.d and they are linked to the init.d script
(which is the same danged script that works interactively via "service tomcat
start/stop"!)
Dan> Where did you get the init script from?
EB> Off the net somewhere, initially. I tweaked it to use sudo to change user
to tomcat:tomcat though, and I changed the chkconfig declaration to be extremely
similar to what nginx uses, since that works fine. chkconfig likes the script, and
sets it up in what looks to be perfect form (comparing to other things). These are
pretty standard scripts though, yes? They basically just delegate to the scripts
distributed with tomcat, which all end up calling catalina.sh :-)
Dan> Since it's not standard, can you include it here? It may be perfectly
fine, but it would be nice to see it regardless.
EB> cat /etc/init.d/tomcat
#!/bin/bash
echo "Let's start Tomcat! ... because Tomcat rocks!" > /tmp/tomcat.log
# chkconfig: - 84 16
# description: Tomcat Start Stop Restart
# processname: tomcat
### BEGIN INIT INFO
# Provides: tomcat
# Required-Start: $local_fs $remote_fs $network
# Required-Stop: $local_fs $remote_fs $network
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: start stop and restart tomcat
### END INIT INFO
JAVA_HOME=/usr/java/jdk1.7.0_45
export JAVA_HOME
PATH=$JAVA_HOME/bin:$PATH
export PATH
CATALINA_HOME=/usr/share/apache-tomcat-7.0.47
echo "JAVA_HOME = $JAVA_HOME" >> /tmp/tomcat.log
echo "PATH = $PATH" >> /tmp/tomcat.log
echo "CATALINA_HOME = $CATALINA_HOME" >> /tmp/tomcat.log
case $1 in
start)
echo "START requested!" >> /tmp/tomcat.log
sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/startup.sh
;;
stop)
echo "STOP requested!" >> /tmp/tomcat.log
sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/shutdown.sh
;;
restart)
echo "RESTART requested!" >> /tmp/tomcat.log
sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/shutdown.sh
sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/startup.sh
;;
esac
exit 0
This won't work.
1. Use JRE_HOME and set it to where your JRE is installed
Technically you can use JAVA_HOME, but Tomcat no longer needs javac
(unless you've changed the stock configuration).
2. sudo won't work if you have SELinux enabled
use /sbin/runuser
3. I use catalina.sh
My command to start Tomcat ends up looking like this:
$SU - $TOMCAT_USER -c "${CONFIG_OPTS} ${CAT_PID} ${TOMCAT_INSTANCE}"
start > $SERVICE_LOG 2>1&!
(obviously all on one line)
where:
$SU is the proper su command (/sbin/su or /sbin/runuser)
$TOMCAT_USER is the tomcat user
$CONFIG_OPTS contains all of the options:
CATALINA_HOME
CATALINA_BASE
JRE_HOME
$CAT_PID is the pid file to write
$TOMCAT_INSTANCE is $CATALINA_HOME/bin/catalina.sh
$SERVICE_LOG is where I write my service startup and shutdown messages
I run multiple Tomcats from one CATALINA_HOME (see RUNNING.txt in the
Tomcat distribution). Each Tomcat gets its own init script, and each
init script reads a corresponding configuration file that sets
CATALINA_HOME, CATALINA_BASE, the PID file, and JRE_HOME. That way I can
run multiple versions of Tomcat with different JREs and still use one
init script (copied to a new service name for each Tomcat).
While the stop command is the same as the start command (just substitute
stop for start), there are some other issues you have to worry about.
1. Is it really running?
2. Did it really stop?
Some misbehaving applications make it difficult to stop Tomcat. I
currently loop for a configurable amount of time, and check the status
of Tomcat once per second. If I fail to stop Tomcat after the
configurable amount of time, I issue a kill -9. That's all logged so I
know which Tomcat is causing problems, and I have a
Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
Some replies inline: Summary: I run lots of Tomcats from init scripts on CentOS 6.5. The init script is . . . ugly. Mine is 500+ lines long. I'd recommend looking at commons-daemon. Tomcat comes with a script that can be used as a starting point (daemon.sh) http://tomcat.apache.org/tomcat-7.0-doc/setup.html#Unix_daemon On 1/15/2014 8:19 AM, Daniel Mikusa wrote: On Jan 15, 2014, at 11:01 AM, "Bush, Eddie" wrote: -Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Wednesday, January 15, 2014 9:54 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: Howdy, List! I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but for my new client I'm also charged with configuring our machines. We're running on Tomcat 7, so I grabbed the tgz and installed it per the instructions. Everything works great! ... until I reboot the server :) At that point, everything else comes up, but tomcat does not. I have removed all logs and rebooted and see nothing notable in any of the tomcat logs (because, of course, it did not start), nor can I find anything in syslog or messages. The chkconfig command reports that the script is configured to run for runlevel 2-5, and I've even inspected the links in rc.d/rc*.d and they are linked to the init.d script (which is the same danged script that works interactively via "service tomcat start/stop"!) Dan> Where did you get the init script from? EB> Off the net somewhere, initially. I tweaked it to use sudo to change user to tomcat:tomcat though, and I changed the chkconfig declaration to be extremely similar to what nginx uses, since that works fine. chkconfig likes the script, and sets it up in what looks to be perfect form (comparing to other things). These are pretty standard scripts though, yes? They basically just delegate to the scripts distributed with tomcat, which all end up calling catalina.sh :-) Since it's not standard, can you include it here? It may be perfectly fine, but it would be nice to see it regardless. EB, one of the places I started with was the Tomcat script in the distribution package. Unfortunately, that way lies madness. Also, can you confirm that the init script is actually being called? It would be helpful to know how far things get before they break down. Since you've said that *no* Tomcat logs get created, I would expect that things don't get very far. Maybe add some logging / echo statements to see what does and doesn't run. Some things to consider when you're writing your Tomcat script: 1. Do you run with SELinux enabled? If so, use /sbin/runuser instead of su 2. Do you write your PID files in the standard RedHat locations? If so, make sure that the directory is read/write for the user Tomcat is run under. 3. Do you write any service startup and shutdown logs? If so, make sure that the directory is read/write for the user Tomcat is run under. This may be more of a *nix question than a tomcat question, but I thought I'd try here first since it is in the context of tomcat itself. Thoughts? Suggestions? Dan> Have you verified that user / permissions are set correct to run as a service? Keep in mind that running as a service may be running Tomcat as a different user. EB> I guess I'm not sure what you mean here. Apologies. However, I did chown -R tomcat:tomcat on the entire install. First start after that reminded me I needed to clean the logs out before expecting it to work :-) but I can now start this interactively using "sudo service tomcat start" and stop it, etc. EB> Perhaps I should add that I was raised on Unix, including being schooled in Unix administration. It's been years, but I do have a decent amount of experience with Unix, shell scripting, etc. :-) Sounds like you've got the general idea of what I was saying here. Good to know how the permissions are set on the Tomcat directory. Dan Dan I have Google'd myself to death! I'm at my wits end! I'm honestly at the point of thinking about punting this issue until another day or possibly resigning to making sure that any workflow which involves a server reboot includes a step for starting tomcat (yuck!). Thanks in advance for any input! Eddie There are a lot of other housekeeping things to do before starting up Tomcat. Also, if you have misbehaving applications you'll want to write fairly robust shutdown and restart functions. However, first things first: 1. Make sure you're using the correct su command (surunner or su) 2. Make sure all of the ancillary directories (see above) have the right permissions When I searched for a startup script a few years ago, I couldn't find one either. I started with the CentOS distribution script, but that quickly became a mess. It dynamically configures ports (for starters) to handle multiple Tomcat instances. My script works, but it's pretty muc
Re: jasper2 doesn't support the "validateXml" attribute
Gernot wrote:
>Hi,
>
>I did an upgrade from tomcat 7.0.29 to 7.0.50.
>In 7.0.50 jasper2 ant task quits with error 'jasper2 doesn't support
>the
>"validateXml" attribute'
>
>Here's the mentioned code:
> uriroot="${build}"
> webXmlFragment="${build}/WEB-INF/generated_web.xml"
> addWebXmlMappings="true"
> outputDir="${build}/WEB-INF/classes"
> compilerSourceVM="7.0"
> compilerTargetVM="7.0" />
>
>
>I havn't found any information about this in tomcat's changelog.
>Is this a bug? Or a feature?
>What's the suggested way to handle this error?
>
>Thanks
It got renamed to validateTld to better describe what it actually does as part
of the XML work in 7.0.48 (which wasn't released until 7.0.50). I see at least
one place in the docs where this wasn't changed. I'll get that fixed for the
next release. If this turns out to be a problem for folks we can add support
for the old name as well.
Mark
-
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
tomcat 7 with APR connector on ubuntu
Hello, I am trying to configure tomcat 7 on ubuntu machine and wanted to run it as non-root on port 80, Here is what I did so far: OS (Ubuntu 12.04 LTS): - installed oracle JDK 1.7.0_45 using "apt-get" - downloaded and extracted tomcat 7.0.50 (.gz format) - created ubuntu user 'tomcat' and granted 'chown -R CATALINA_HOME' to this user - changed tomcat default port to 80 in server.xml - installed and configured authbind tool - created sh script "/etc/init.d/tomcat7" to start tomcat as tomcat user. - tomcat 7 was working as expected on 80 port as non-root user. - later I configured APR 1.5.0 and tried to run tomcat again, I got this error: Jan 15, 2014 6:24:45 AM org.apache.catalina.core.AprLifecycleListener init INFO: Loaded APR based Apache Tomcat Native library 1.1.29 using APR version 1.5.0. Jan 15, 2014 6:24:45 AM org.apache.catalina.core.AprLifecycleListener init INFO: APR capabilities: IPv6 [true], sendfile [true], accept filters [false], random [true]. Jan 15, 2014 6:24:46 AM org.apache.catalina.core.AprLifecycleListener initializeSSL INFO: OpenSSL successfully initialized (OpenSSL 1.0.1 14 Mar 2012) Jan 15, 2014 6:24:46 AM org.apache.coyote.AbstractProtocol init INFO: Initializing ProtocolHandler ["http-apr-80"] Jan 15, 2014 6:24:46 AM org.apache.coyote.AbstractProtocol init SEVERE: Failed to initialize end point associated with ProtocolHandler ["http-apr-80"] java.lang.Exception: Socket bind failed: [13] Permission denied at org.apache.tomcat.util.net.AprEndpoint.bind(AprEndpoint.java:430) at org.apache.tomcat.util.net.AbstractEndpoint.init(AbstractEndpoint.java:640) at org.apache.coyote.AbstractProtocol.init(AbstractProtocol.java:434) at org.apache.catalina.connector.Connector.initInternal(Connector.java:981) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardService.initInternal(StandardService.java:559) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.core.StandardServer.initInternal(StandardServer.java:814) at org.apache.catalina.util.LifecycleBase.init(LifecycleBase.java:102) at org.apache.catalina.startup.Catalina.load(Catalina.java:639) at org.apache.catalina.startup.Catalina.load(Catalina.java:664) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.load(Bootstrap.java:281) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:455) If I am removing out this line from server.xml: Tomcat working on 80 port as non-root user and starting "http-bio-80" properly. Another thing is if I am trying to run tomcat as "root" along with APR support, its working just fine. Any advise why its working on "http-bio-80" while throwing bind exception on "http-apr-80"?? Regards, Mubeen
RE: [tomcat7] rhel 6 - init.d script works; does not start on reboot
-Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Wednesday, January 15, 2014 10:19 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot On Jan 15, 2014, at 11:01 AM, "Bush, Eddie" wrote: > > > -Original Message- > From: Daniel Mikusa [mailto:dmik...@gopivotal.com] > Sent: Wednesday, January 15, 2014 9:54 AM > To: Tomcat Users List > Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot > > On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: > >> Howdy, List! >> >> I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but >> for my new client I'm also charged with configuring our machines. We're >> running on Tomcat 7, so I grabbed the tgz and installed it per the >> instructions. >> >> Everything works great! ... until I reboot the server :) At that point, >> everything else comes up, but tomcat does not. >> >> I have removed all logs and rebooted and see nothing notable in any of the >> tomcat logs (because, of course, it did not start), nor can I find anything >> in syslog or messages. The chkconfig command reports that the script is >> configured to run for runlevel 2-5, and I've even inspected the links in >> rc.d/rc*.d and they are linked to the init.d script (which is the same >> danged script that works interactively via "service tomcat start/stop"!) > > Dan> Where did you get the init script from? > EB> Off the net somewhere, initially. I tweaked it to use sudo to change user > to tomcat:tomcat though, and I changed the chkconfig declaration to be > extremely similar to what nginx uses, since that works fine. chkconfig likes > the script, and sets it up in what looks to be perfect form (comparing to > other things). These are pretty standard scripts though, yes? They basically > just delegate to the scripts distributed with tomcat, which all end up > calling catalina.sh :-) Dan> Since it's not standard, can you include it here? It may be perfectly fine, but it would be nice to see it regardless. EB> cat /etc/init.d/tomcat #!/bin/bash echo "Let's start Tomcat! ... because Tomcat rocks!" > /tmp/tomcat.log # chkconfig: - 84 16 # description: Tomcat Start Stop Restart # processname: tomcat ### BEGIN INIT INFO # Provides: tomcat # Required-Start: $local_fs $remote_fs $network # Required-Stop: $local_fs $remote_fs $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # Short-Description: start stop and restart tomcat ### END INIT INFO JAVA_HOME=/usr/java/jdk1.7.0_45 export JAVA_HOME PATH=$JAVA_HOME/bin:$PATH export PATH CATALINA_HOME=/usr/share/apache-tomcat-7.0.47 echo "JAVA_HOME = $JAVA_HOME" >> /tmp/tomcat.log echo "PATH = $PATH" >> /tmp/tomcat.log echo "CATALINA_HOME = $CATALINA_HOME" >> /tmp/tomcat.log case $1 in start) echo "START requested!" >> /tmp/tomcat.log sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/startup.sh ;; stop) echo "STOP requested!" >> /tmp/tomcat.log sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/shutdown.sh ;; restart) echo "RESTART requested!" >> /tmp/tomcat.log sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/shutdown.sh sudo -g tomcat -u tomcat sh $CATALINA_HOME/bin/startup.sh ;; esac exit 0 Dan> Also, can you confirm that the init script is actually being called? It would be helpful to know how far things get before they break down. Since you've said that *no* Tomcat logs get created, I would expect that things don't get very far. Maybe add some logging / echo statements to see what does and doesn't run. EB> Genius suggestion. I'm disappointed I didn't think about it. Turns out that it does try to start. EB> cat /tmp/tomcat.log Let's start Tomcat! ... because Tomcat rocks! JAVA_HOME = /usr/java/jdk1.7.0_45 PATH = /usr/java/jdk1.7.0_45/bin:/sbin:/usr/sbin:/bin:/usr/bin CATALINA_HOME = /usr/share/apache-tomcat-7.0.47 START requested! EB> So it feels like that sudo command fails. However, I see nothing in /var/log/sudolog. Is sudo the issue? EB> I was trying su in the script, but it complained about the account not having login enabled. sudo worked interactively, so I assumed that ought to work! EB> I looked at adding jsvc, but I don't have a lot of control over channels that the machine is subscribed to, and that seems to be in the optional channel. EB> I have (rhel6) a daemon command, and I had considered updating to use that, but the sudo works interactively so I stuck with that (if it ain't broke, right?) > >> >> This may be more of a *nix question than a tomcat question, but I thought >> I'd try here first since it is in the context of tomcat itself. >> >> Thoughts? Suggestions? > > Dan> Have you verified that user / permissions are set correct to run as a > service? Keep in mind that running as a service may be running Tomcat as a > different user. > EB> I guess I'm not sure what you mean here. Apologies. However, I did chown > -R tomcat:tomcat on the entire install. First st
jasper2 doesn't support the "validateXml" attribute
Hi, I did an upgrade from tomcat 7.0.29 to 7.0.50. In 7.0.50 jasper2 ant task quits with error 'jasper2 doesn't support the "validateXml" attribute' Here's the mentioned code: I havn't found any information about this in tomcat's changelog. Is this a bug? Or a feature? What's the suggested way to handle this error? Thanks
Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
On Jan 15, 2014, at 11:01 AM, "Bush, Eddie" wrote: > > > -Original Message- > From: Daniel Mikusa [mailto:dmik...@gopivotal.com] > Sent: Wednesday, January 15, 2014 9:54 AM > To: Tomcat Users List > Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot > > On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: > >> Howdy, List! >> >> I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but >> for my new client I'm also charged with configuring our machines. We're >> running on Tomcat 7, so I grabbed the tgz and installed it per the >> instructions. >> >> Everything works great! ... until I reboot the server :) At that point, >> everything else comes up, but tomcat does not. >> >> I have removed all logs and rebooted and see nothing notable in any of the >> tomcat logs (because, of course, it did not start), nor can I find anything >> in syslog or messages. The chkconfig command reports that the script is >> configured to run for runlevel 2-5, and I've even inspected the links in >> rc.d/rc*.d and they are linked to the init.d script (which is the same >> danged script that works interactively via "service tomcat start/stop"!) > > Dan> Where did you get the init script from? > EB> Off the net somewhere, initially. I tweaked it to use sudo to change user > to tomcat:tomcat though, and I changed the chkconfig declaration to be > extremely similar to what nginx uses, since that works fine. chkconfig likes > the script, and sets it up in what looks to be perfect form (comparing to > other things). These are pretty standard scripts though, yes? They basically > just delegate to the scripts distributed with tomcat, which all end up > calling catalina.sh :-) Since it's not standard, can you include it here? It may be perfectly fine, but it would be nice to see it regardless. Also, can you confirm that the init script is actually being called? It would be helpful to know how far things get before they break down. Since you've said that *no* Tomcat logs get created, I would expect that things don't get very far. Maybe add some logging / echo statements to see what does and doesn't run. > >> >> This may be more of a *nix question than a tomcat question, but I thought >> I'd try here first since it is in the context of tomcat itself. >> >> Thoughts? Suggestions? > > Dan> Have you verified that user / permissions are set correct to run as a > service? Keep in mind that running as a service may be running Tomcat as a > different user. > EB> I guess I'm not sure what you mean here. Apologies. However, I did chown > -R tomcat:tomcat on the entire install. First start after that reminded me I > needed to clean the logs out before expecting it to work :-) but I can now > start this interactively using "sudo service tomcat start" and stop it, etc. > EB> Perhaps I should add that I was raised on Unix, including being schooled > in Unix administration. It's been years, but I do have a decent amount of > experience with Unix, shell scripting, etc. :-) Sounds like you've got the general idea of what I was saying here. Good to know how the permissions are set on the Tomcat directory. Dan > > Dan > >> I have Google'd myself to death! I'm at my wits end! I'm honestly at the >> point of thinking about punting this issue until another day or possibly >> resigning to making sure that any workflow which involves a server reboot >> includes a step for starting tomcat (yuck!). >> >> Thanks in advance for any input! >> >> Eddie >> >> > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: Oracle Application Server 10g R3 works fine with RK-1048 codepage but Tomcat 7.0.47 does not.
Hello, Chris ! I applied settings you adviced: Don't you want user.langauge=RU user.country=kz? [oracle@n36 logs]$ echo $JAVA_OPTS -XX:MaxPermSize=128M -Xms256m -Xmx1024m -Duser.language=RU -Duser.country=kz But our java-application gives the following message: 15.01.2014 21:41:01 org.apache.catalina.core.ApplicationContext log MESSAGE = ORA-00604: error occurred at recursive SQL level 1 ORA-12705: invalid or unknown NLS parameter value specified , ERRORCODE = 604 So, there can be problems in a couple of places. If you have an extended characters correctly-stored in the Oracle database, will it display correctly if you try to show it on a web page? Let's make sure that works first, then we'll tackle submitting such characters via forms. Note that using extended characters in GET requests is a nightmare: you should try to avoid it at all costs. There are two state languages in Kazakhstan - Russian and Kazakh and both must be supported. Our Oracle database works in single-byte cyrillic encoding and its size is up to 1 tB now. If we convert one to Unicode it will be ~2 tB which is impossible for us as no disk space. Our java servlet was created based on Oracle UIX technology which is old enough. Within seven years we successfully use this servlet with Oracle Application Server 10g R2/R3 (now OAS 10.1.3.5). There are not any troubles with Kazakh letters displaying on web-pages with Oracle Application Server. But Tomcat gives troubles with Kazakh letters displaying. What difference between Oracle Application Server and Tomcat in characters processing ? In production we still use this servlet with Oracle Application Server. I can see any its settings if you tell me which ones to check. >From Tomcat doc I see that we can convert GET-request to specified code page by using "URIEncoding" in http-connector definition of server.xml. I have tried to use the followng: <--also tried without this one May be we must do some tracing to understand the root of the trouble ? Thank you for your helping me. Waiting for your advices, Timur 2014/1/14 Christopher Schultz > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > Тимур, > > On 1/14/14, 2:44 AM, Тимур Кулибаев wrote: > > The "user.language" and "user.country" system properties for my > > running Tomcat instance are not set. > > They must be set to something. If you are not explicitly-setting them, > then they are defaulting to something, negotiated by the OS and the JVM. > > > In Oracle Apllication Server I also do not see these properties set > > in "ps -ef | grep java" output. I set both properties in JAVA_OPTS > > env.var: > > > > [oracle@n36 logs]$ echo $JAVA_OPTS -XX:MaxPermSize=128M -Xms256m > > -Xmx1024m -Duser.language=ru -Duser.country=RU > > > > Check whether java process has these settings: [oracle@n36 logs]$ > > ps -ef | grep java oracle 17311 1 18 13:31 pts/000:00:41 > > > /u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/jdk-6u38-linux/jdk1.6.0_38/bin/java > > > > > - > > -Djava.util.logging.config.file=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/conf/logging.properties > > -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager > > -XX:MaxPermSize=128M -Xms256m -Xmx1024m -Duser.language=ru > > -Duser.country=RU > > > -Djava.endorsed.dirs=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/endorsed > > > > > - -classpath > > > /u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/bin/bootstrap.jar:/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/bin/tomcat-juli.jar > > > > > - > > -Dcatalina.base=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47 > > > -Dcatalina.home=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47 > > > > > - > > -Djava.io.tmpdir=/u02/apache_software/apache-tomcat-7.0.47/apache-tomcat-7.0.47/temp > > org.apache.catalina.startup.Bootstrap start oracle 17369 17164 0 > > 13:35 pts/000:00:00 grep java > > > > After setting "user.language" and "user.country" I tested servlet > > on Tomcat 7 again but it didn't help, trouble persists. What else > > are to be fixed in Tomcat conf ? > > Don't you want user.langauge=RU user.country=kz? > > If your computer is already set up to use that special addition to > WINDOWS-1215, then you should probably be good to go. > > > PS: I'm in Kazakhstan, at GMT+6, so sorry for delay with answer. > > It's no problem at all. > > So, there can be problems in a couple of places. If you have an > extended characters correctly-stored in the Oracle database, will it > display correctly if you try to show it on a web page? Let's make sure > that works first, then we'll tackle submitting such characters via forms. > > Note that using extended characters in GET requests is a nightmare: > you should try to avoid it at all costs. > > - -chris > -BEGIN PGP SIGNATURE- > Version: GnuPG v1 > Comment: GPGTools - http://gpgtools.org > Comment: Using GnuPG with
RE: [tomcat7] rhel 6 - init.d script works; does not start on reboot
Gene - chkconfig thinks everything is copasetic and reports that it should be starting in runlevel 2-5. All the links have been created properly in the rc#.d directories that correspond to runlevel 2-5. They all point to the init.d script :-) and are permissioned identically to other links/scripts. -Original Message- From: Gene Matthews [mailto:genem8...@icloud.com] Sent: Wednesday, January 15, 2014 10:02 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot On Jan 15, 2014, at 10:32 AM, Bush, Eddie wrote: > Everything works great! ... until I reboot the server :) At that point, > everything else comes up, but tomcat does not. > Not sure what OS you are running, but in CentOS you can use the chkconfig command to see at what run levels that script is set to start. You can use the same command to set the script to start at certain run levels. Gene - 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: [tomcat7] rhel 6 - init.d script works; does not start on reboot
-Original Message- From: Daniel Mikusa [mailto:dmik...@gopivotal.com] Sent: Wednesday, January 15, 2014 9:54 AM To: Tomcat Users List Subject: Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: > Howdy, List! > > I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but > for my new client I'm also charged with configuring our machines. We're > running on Tomcat 7, so I grabbed the tgz and installed it per the > instructions. > > Everything works great! ... until I reboot the server :) At that point, > everything else comes up, but tomcat does not. > > I have removed all logs and rebooted and see nothing notable in any of the > tomcat logs (because, of course, it did not start), nor can I find anything > in syslog or messages. The chkconfig command reports that the script is > configured to run for runlevel 2-5, and I've even inspected the links in > rc.d/rc*.d and they are linked to the init.d script (which is the same danged > script that works interactively via "service tomcat start/stop"!) Dan> Where did you get the init script from? EB> Off the net somewhere, initially. I tweaked it to use sudo to change user to tomcat:tomcat though, and I changed the chkconfig declaration to be extremely similar to what nginx uses, since that works fine. chkconfig likes the script, and sets it up in what looks to be perfect form (comparing to other things). These are pretty standard scripts though, yes? They basically just delegate to the scripts distributed with tomcat, which all end up calling catalina.sh :-) > > This may be more of a *nix question than a tomcat question, but I thought I'd > try here first since it is in the context of tomcat itself. > > Thoughts? Suggestions? Dan> Have you verified that user / permissions are set correct to run as a service? Keep in mind that running as a service may be running Tomcat as a different user. EB> I guess I'm not sure what you mean here. Apologies. However, I did chown -R tomcat:tomcat on the entire install. First start after that reminded me I needed to clean the logs out before expecting it to work :-) but I can now start this interactively using "sudo service tomcat start" and stop it, etc. EB> Perhaps I should add that I was raised on Unix, including being schooled in Unix administration. It's been years, but I do have a decent amount of experience with Unix, shell scripting, etc. :-) Dan > I have Google'd myself to death! I'm at my wits end! I'm honestly at the > point of thinking about punting this issue until another day or possibly > resigning to making sure that any workflow which involves a server reboot > includes a step for starting tomcat (yuck!). > > Thanks in advance for any input! > > Eddie > > - 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: [tomcat7] rhel 6 - init.d script works; does not start on reboot
On Jan 15, 2014, at 10:32 AM, Bush, Eddie wrote: > Everything works great! ... until I reboot the server :) At that point, > everything else comes up, but tomcat does not. > Not sure what OS you are running, but in CentOS you can use the chkconfig command to see at what run levels that script is set to start. You can use the same command to set the script to start at certain run levels. Gene - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: [tomcat7] rhel 6 - init.d script works; does not start on reboot
On Jan 15, 2014, at 10:32 AM, "Bush, Eddie" wrote: > Howdy, List! > > I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but > for my new client I'm also charged with configuring our machines. We're > running on Tomcat 7, so I grabbed the tgz and installed it per the > instructions. > > Everything works great! ... until I reboot the server :) At that point, > everything else comes up, but tomcat does not. > > I have removed all logs and rebooted and see nothing notable in any of the > tomcat logs (because, of course, it did not start), nor can I find anything > in syslog or messages. The chkconfig command reports that the script is > configured to run for runlevel 2-5, and I've even inspected the links in > rc.d/rc*.d and they are linked to the init.d script (which is the same danged > script that works interactively via "service tomcat start/stop"!) Where did you get the init script from? > > This may be more of a *nix question than a tomcat question, but I thought I'd > try here first since it is in the context of tomcat itself. > > Thoughts? Suggestions? Have you verified that user / permissions are set correct to run as a service? Keep in mind that running as a service may be running Tomcat as a different user. Dan > I have Google'd myself to death! I'm at my wits end! I'm honestly at the > point of thinking about punting this issue until another day or possibly > resigning to making sure that any workflow which involves a server reboot > includes a step for starting tomcat (yuck!). > > Thanks in advance for any input! > > Eddie > > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
[tomcat7] rhel 6 - init.d script works; does not start on reboot
Howdy, List! I'm in a bit of a pickle here. I'm a senior dev, and quite good at that, but for my new client I'm also charged with configuring our machines. We're running on Tomcat 7, so I grabbed the tgz and installed it per the instructions. Everything works great! ... until I reboot the server :) At that point, everything else comes up, but tomcat does not. I have removed all logs and rebooted and see nothing notable in any of the tomcat logs (because, of course, it did not start), nor can I find anything in syslog or messages. The chkconfig command reports that the script is configured to run for runlevel 2-5, and I've even inspected the links in rc.d/rc*.d and they are linked to the init.d script (which is the same danged script that works interactively via "service tomcat start/stop"!) This may be more of a *nix question than a tomcat question, but I thought I'd try here first since it is in the context of tomcat itself. Thoughts? Suggestions? I have Google'd myself to death! I'm at my wits end! I'm honestly at the point of thinking about punting this issue until another day or possibly resigning to making sure that any workflow which involves a server reboot includes a step for starting tomcat (yuck!). Thanks in advance for any input! Eddie
Re: Tomcat strips CRLFs from the generated page
On Wed, Jan 15, 2014 at 4:15 PM, André Warnier wrote: > >> On Wed, Jan 15, 2014 at 7:34 AM, André Warnier wrote: >> >> Asok Chattopadhyay wrote: >>> >>> It looks like, the problem may be caused due to some scripts being inserted into the page by an external domain. I am investigating farther on that line. Thanks everybody. Thank you anyway for writing this. It allows us (and anyone else >>> consulting the email archives later) to see some logical end to the >>> issue. >>> >>> But I have to say that considering your earlier descriptions of the issue >>> (a servlet just reading a local file and sending it), what you mention >>> above doesn't quite fit. >>> An "external domain" cannot just "insert some scripts" into a static page >>> on the server, can it ? >>> I'd be curious to see a real full and accurate explanation of the >>> problem, >>> later. >>> >>> > > You keep top-posting, which is not nice. > Here is how it's done : > > Sorry about that! I am using gmail and it shows a box for reply and I just used that. May be this time it should be OK. > > Asok Chattopadhyay wrote: > > Thanks Andre, > > > > Whenever, the CRLFs are stripped, I find an extra line of script in the > > page when I View source. The line was not in the original file test.html. > > > > Here is the extra line inserted: > > > > http://wac.edgecastcdn.net/800952/400b1e1c-5766-45fe- > a132-1e98616c551e-api/gsrs?g=dae3ecf9-dab8-409b-952c- > c2eb328442d9&is=trlssg > > "> > > > > I have no idea how and when this get inserted. I set the browser to > "Always > > send Do Not Track header", yet it keeps coming. I have inserted a routine > > to monitor all external scripts while I look for an appropriate forum > that > > could help me. > > > > Well, you are probably right to worry, but not about Tomcat. > > If you are on a Windows PC, do this : > - install "wget" (you'll find it on the WWW) > - do : > cd \temp > C:\temp>wget -O suspect.js "http://wac.edgecastcdn.net/ > 800952/400b1e1c-5766-45fe-a132-1e98616c551e-api/gsrs?g=dae3ecf9-d > ab8-409b-952c-c2eb328442d9&is=trlssg" > > and then have a look at that "suspect.js" > > Since it is not in the original file on the server, and since I cannot > imagine how anything on the server can just "insert that section" into the > page before returning it, we have to imagine that the insertion happens on > your workstation. > Which looks to me like a possible virus/trojan. > Or an unexpected effect of the javascript that is already in your page, > but possibly malware anyway. > > Scan you PC. > > And I will re-scan mine, because I also viewed your test page. > > A Google search for : who is "wac.edgecastcdn.net" > can be helpful. > > > - > To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > > Thanks, I'll do as you suggest. Regards.
Re: Tomcat strips CRLFs from the generated page
On Wed, Jan 15, 2014 at 7:34 AM, André Warnier wrote: Asok Chattopadhyay wrote: It looks like, the problem may be caused due to some scripts being inserted into the page by an external domain. I am investigating farther on that line. Thanks everybody. Thank you anyway for writing this. It allows us (and anyone else consulting the email archives later) to see some logical end to the issue. But I have to say that considering your earlier descriptions of the issue (a servlet just reading a local file and sending it), what you mention above doesn't quite fit. An "external domain" cannot just "insert some scripts" into a static page on the server, can it ? I'd be curious to see a real full and accurate explanation of the problem, later. You keep top-posting, which is not nice. Here is how it's done : Asok Chattopadhyay wrote: > Thanks Andre, > > Whenever, the CRLFs are stripped, I find an extra line of script in the > page when I View source. The line was not in the original file test.html. > > Here is the extra line inserted: > > http://wac.edgecastcdn.net/800952/400b1e1c-5766-45fe-a132-1e98616c551e-api/gsrs?g=dae3ecf9-dab8-409b-952c-c2eb328442d9&is=trlssg> "> > > I have no idea how and when this get inserted. I set the browser to "Always > send Do Not Track header", yet it keeps coming. I have inserted a routine > to monitor all external scripts while I look for an appropriate forum that > could help me. > Well, you are probably right to worry, but not about Tomcat. If you are on a Windows PC, do this : - install "wget" (you'll find it on the WWW) - do : cd \temp C:\temp>wget -O suspect.js "http://wac.edgecastcdn.net/800952/400b1e1c-5766-45fe-a132-1e98616c551e-api/gsrs?g=dae3ecf9-d ab8-409b-952c-c2eb328442d9&is=trlssg" and then have a look at that "suspect.js" Since it is not in the original file on the server, and since I cannot imagine how anything on the server can just "insert that section" into the page before returning it, we have to imagine that the insertion happens on your workstation. Which looks to me like a possible virus/trojan. Or an unexpected effect of the javascript that is already in your page, but possibly malware anyway. Scan you PC. And I will re-scan mine, because I also viewed your test page. A Google search for : who is "wac.edgecastcdn.net" can be helpful. - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
