You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by André Warnier <aw...@ice-sa.com> on 2011/12/12 17:36:55 UTC
path used for tc-natuve
Hi
On a Debian Linux system, was running a Debian-pre-packaged Tomcat 5.5.
We stopped this Tomcat 5.5, but did not remove the corresponding package(s).
Then we installed an "official" Tomcat 6, downloaded from the Tomcat website, in
/opt/tomcat6 as "CATALINA_HOME".
We then made a copy of the /etc/init.d startup script which used to start Tomcat 5.5, and
modified it to start this new Tomcat6 instead.
Now when stopping and starting this Tomcat6, we are getting the message below (about APR)
in the Tomcat6 logfile.
My question is : where could Tomcat6 find this APR tc-native of the wrong version ?
As far as I can tell, there is no unpacked tc-native anything in the Tomcat6 directories.
Dec 12, 2011 12:37:14 PM org.apache.coyote.http11.Http11Protocol destroy
INFO: Stopping Coyote HTTP/1.1 on http-8180
12.12.2011 12:37:24 org.apache.catalina.core.AprLifecycleListener init
SCHWERWIEGEND: An incompatible version 1.1.12 of the APR based Apache Tomcat Native
library is installed, while Tomcat requires version 1.1.17
12.12.2011 12:37:24 org.apache.coyote.http11.Http11Protocol init
INFO: Initializing Coyote HTTP/1.1 on http-8180
12.12.2011 12:37:24 org.apache.catalina.startup.Catalina load
INFO: Initialization processed in 2079 ms
12.12.2011 12:37:26 org.apache.catalina.core.StandardService start
INFO: Starting service Catalina
12.12.2011 12:37:26 org.apache.catalina.core.StandardEngine start
INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
12.12.2011 12:37:26 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory test
12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory dumpuser
12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig deployDirectory
INFO: Deploying web application directory starweb
12.12.2011 12:37:27 org.apache.coyote.http11.Http11Protocol start
INFO: Starting Coyote HTTP/1.1 on http-8180
12.12.2011 12:37:27 org.apache.jk.common.ChannelSocket init
INFO: JK: ajp13 listening on /0.0.0.0:8009
12.12.2011 12:37:27 org.apache.jk.server.JkMain start
INFO: Jk running ID=0 time=0/55 config=null
12.12.2011 12:37:27 org.apache.catalina.startup.Catalina start
INFO: Server startup in 2993 ms
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Mon, Dec 12, 2011 at 17:36, André Warnier <aw...@ice-sa.com> wrote:
> Hi
>
> On a Debian Linux system, was running a Debian-pre-packaged Tomcat 5.5.
> We stopped this Tomcat 5.5, but did not remove the corresponding package(s).
> Then we installed an "official" Tomcat 6, downloaded from the Tomcat
> website, in /opt/tomcat6 as "CATALINA_HOME".
> We then made a copy of the /etc/init.d startup script which used to start
> Tomcat 5.5, and modified it to start this new Tomcat6 instead.
>
> Now when stopping and starting this Tomcat6, we are getting the message
> below (about APR) in the Tomcat6 logfile.
>
> My question is : where could Tomcat6 find this APR tc-native of the wrong
> version ?
> As far as I can tell, there is no unpacked tc-native anything in the Tomcat6
> directories.
>
>
> Dec 12, 2011 12:37:14 PM org.apache.coyote.http11.Http11Protocol destroy
> INFO: Stopping Coyote HTTP/1.1 on http-8180
> 12.12.2011 12:37:24 org.apache.catalina.core.AprLifecycleListener init
> SCHWERWIEGEND: An incompatible version 1.1.12 of the APR based Apache Tomcat
> Native library is installed, while Tomcat requires version 1.1.17
Can you:
perl -ple 's,\00,\n,g' /proc/$(pgrep java)/environ
and see what LD_LIBRARY_PATH is, if anything? (this is provided that
only one java process is running, otherwise adapt the pgrep command)
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Francis GALIEGUE <fg...@one2team.com>.
On Mon, Dec 12, 2011 at 23:25, André Warnier <aw...@ice-sa.com> wrote:
[...]
>
> 1) these are the tomcat6 processes, as shown by "ps" :
> (sorry for the format, I hope it is readable)
>
> root 21245 1 0 21:19 ? 00:00:00 /usr/bin/jsvc -user tomcat55
> -cp /usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar
> -outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
> -Djava.awt.headless=true -Xms256M -Xmx256M
> -Djava.endorsed.dirs=/opt/tomcat6/common/endorsed
> -Dcatalina.base=/opt/tomcat6 -Dcatalina.home=/opt/tomcat6
> -Djava.io.tmpdir=/opt/tomcat6/temp
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
> org.apache.catalina.startup.Bootstrap
>
Ah, jsvc... I though you invoked the JVM directly.
Does it have a configuration file? I have never used it, but I'd
definitely look there. There is no reason at all why the JVM alone
would play with shared objects unless you ask it to.
--
Francis Galiegue
ONE2TEAM
Ingénieur système
Mob : +33 (0) 683 877 875
Tel : +33 (0) 178 945 552
fge@one2team.com
40 avenue Raymond Poincaré
75116 Paris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
All,
On 12/13/11 3:01 PM, Christopher Schultz wrote:
> I think Andre's original problem wasn't with tcnative, but with
> libapr. If you build the new tcnative dynamically-linked, then
> you're going to have the same problem.
Er, nevermind: it *was* tcnative.
I don't think the current versions of tcnative require apr 1.4, but I
know that trunk requires a higher version (1.4) than most people
usually have (1.2).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ntv4ACgkQ9CaO5/Lv0PBg+ACgxB9W+1x3qPOE+H39d8Ch2gfR
aioAoMQDhkRdzS8DmjruqWXTWwydMUBP
=2W86
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 12/14/11 2:57 AM, André Warnier wrote:
> [T]hat's exactly why, for the time being, I have decided to do
> without tc-native. The first line I saw in the tc-native source
> README was something like "to build, you may need OpenSSL xx .."
> and then I started getting cold feet, remembering my previous
> experiences going along the dependencies-from-hell route umpteen
> times before.
Surely you have libssl installed? If you have a Linux system and don't
have libssl installed, you need to re-think that decision. libssl is
required for OpenSSH, and if you aren't running OpenSSH then your box
is inert. Unless you're running telnetd. Are you?
> And in this case, we're talking indeed about a system which already
> has all those nice symlinks all over the place.. What is it he said
> ? "once you give in to the dark side of the Force, forever dominate
> you it will.." If apt-get is the dark side, then I guess I'm
> already on Darth's side.
I've found apt-get to be fairly good with standard *NIX-y stuff. It's
the Java things that the package maintainers tend to ... unnecessarily
customize.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qEiQACgkQ9CaO5/Lv0PAQfACfdCxupsNU/tcNrvTgo0wUDkyc
UaoAn3JMdEPFdadAECErhhA+0n93+gXb
=YZ9X
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 12/15/11 11:08 AM, Gregor S. wrote:
> On Thu, Dec 15, 2011 at 4:34 PM, Christopher Schultz
> <ch...@christopherschultz.net> wrote:
>>
>> I think that's a bad idea because then you have built your
>> libtcnative (which can be considered Tomcat-version-specific, or
>> at least Tomcat-version-sensitive) for the whole system to use
>> and that essentially locks you into that version regardless of
>> Tomcat version being run at the time.
>
> True. However, I guess it's a bad idea to run two different
> versions of Tomcat on the same box.
Huh? Why not?
We run two versions of Tomcat next to each other in production, mostly
because certain applications have been tested on the newer versions
and others have been happily running on older versions. We make heavy
use of CATALINA_BASE and everything runs quite happily. We even run
two separate versions of Java for the same reason.
> When compiling, libtcnative goes to
> $CATALINA_HOME//bin/tomcat-native-1.1.20-src/jni/native/.lib
> (dpeneding on the tomcat-native-version).
I would just shove it into CATALINA_HOME/bin.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qIzoACgkQ9CaO5/Lv0PA6kQCgnWO9Tpm+9tji82yo3sIFKMnf
1aQAnRVU+S8hibfDyPvAJBFZ3G+zzNyM
=IE2y
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 12/16/11 3:50 AM, Gregor S. wrote:
> Chris:
>
>> IIRC, Tomcat loads tcnative without a version number in it's name
>> even when it prefers a version that is of a certain level.
>
> I don't believe you're right, since when I upgraded Tomcat5.5
> having an old version of tcnative installed, Tomcat 6 refused to
> start requiring a more recent version of tcnative.
What I meant to say was that Library.java (I confirmed) asks for
"tcnative-1" and not, say, "tcnative-1.1.17". That makes sense, since
the idea is that any version of tcnative "high enough" ought to be
good enough. That's why the code-based version check is done: to make
sure that a "high enough" version is available.
For instance, tcnative-2.0 would also work, but requiring "tcnative-2"
wouldn't be correct.
IMHO, such a breaking change should have been accompanied by a minor
version bump, so that Tomcat could request "tcnative-1.2" and allow
any tcnative-1.2.x version to be loaded (through the magic of
filesystem symlinking).
It would be great if dlopen understood how to resolve dependencies
like "at least version 1.1.17" but that would probably require
programmers and package maintainers to be very careful about metadata
or nothing would work.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7ruMIACgkQ9CaO5/Lv0PC7WACdGv8CsA+z3TXdsYcwxLXoU3tk
im8AnjGznagmJibyAeHxyWqWgd0WElr+
=TwgH
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by "Gregor S." <rc...@googlemail.com>.
Guys,
I feel you're seeing thing way too complicated.
Chris:
> IIRC, Tomcat loads tcnative without a version number in it's name even
> when it prefers a version that is of a certain level.
I don't believe you're right, since when I upgraded Tomcat5.5 having
an old version of tcnative installed, Tomcat 6 refused to start
requiring a more recent version of tcnative.
André:
As I wrote on top, you can tell Catalina where to look for libtcnative.
The LD_LIBRARY_PATH should do the trick, but I wouldn't set it
system.wide since this variable is also requested from other
processes. A change here might have impacts.
Therefore, just pass it as a Java-property to Catalina and let
Catalina know where to look for it:
Just adapt the CATALINA_OPTS in Tomcat's startup-script:
CATALINA_OPTS=$CATALINA_OPTS -Djava.library.path=[path to where
libtcnative is located]
Doing so, you can run as many different versions of Tomcat referring
to different version of libtcnative.
Cheers!
Gregor
--
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@ice-sa.com]
>> Subject: Re: path used for tc-natuve
>
>> This left me intellectually unsatisfied, because I still
>> did not know how Tomcat6 was finding this old tc-native,
>
> Already told you: dlopen() is required to look in /usr/lib - as a last resort. Check out the man page for that API.
>
Yes, and I did play a bit more on the Dummy side than strictly necessary.
But, on the other hand, knowing that "dlopen()" is involved is not exactly evident (as you
noted yourself), and it still does not really say *who* is calling dlopen(), nor why
dlopen() would ever look into (tomcat_dir)/bin.
But let's switch to Christopher's answer for the rest.
In any case, thank you both for your patience and for the great information.
I think I got it now.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: path used for tc-natuve
> This left me intellectually unsatisfied, because I still
> did not know how Tomcat6 was finding this old tc-native,
Already told you: dlopen() is required to look in /usr/lib - as a last resort. Check out the man page for that API.
> there is nothing really obvious in the documentation which
> explains where it is looking. (Probably because to Real Java
> Programmers, this is too obvious; but I am not a Real Java
> Programmer).
Nothing to do with Java; it's platform-specific, so Java-only programmers wouldn't know either.
> I believe that if, in the script which starts Tomcat6, I would add
> something like export LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH
> that might do the trick as far as tc-native is concerned.
Only if there were something in /opt/tomcat6/bin to find; if not dlopen() will keep looking until it hits /usr/lib.
> The JVM is native code, so it looks along it's own "library path"
> to find the desired module.
No, the JVM just calls dlopen() and lets the linker figure out where to look. The parameter to dlopen() may include a path, but usually doesn't, in which case the standard list of places is employed.
- 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.
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Christopher.
looks like I have some reading for the week-end.
Thanks for all the info.
Here is just the answer to your question :
Christopher Schultz wrote:
>
> Try running this from the command line:
>
> $ dpkg -S /usr/lib/tcnative.so (or whatever the exact filename is)
>
> That will tell you what package it came from, or it will tell you that
> it's "not found" which means that it wasn't found in any installed
> package. That would mean that it was installed manually by someone.
v2:~# dpkg -S /usr/lib/libtcnative-1.so.0.1.12
libtcnative-1: /usr/lib/libtcnative-1.so.0.1.12
v2:~# apt-cache search libtcnative-1
libtcnative-1 - Tomcat native library using the apache portable runtime
So it was it's own package.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Christopher Schultz [mailto:chris@christopherschultz.net]
> Subject: Re: path used for tc-natuve
> dlopen does not take a search path as a parameter -- it always uses
> LD_LIBRARY_PATH.
Well... no. If a slash is included in the dlopen() argument, that is taken to be a path; it can be relative or absolute. If no slash is present, then dlopen() searches in this order:
1) the DT_RPATH tag of the executing program, if DT_RUNPATH isn't present
2) the value of LD_LIBRARY_PATH at the time execution started (so you can't modify it on the fly)
3) the DT_RUNPATH tag of the executing program
4) the files listed in /etc/ld.so.cache
5) /lib
6) /usr/lib
> It could modify it's own environment variable by constructing
> LD_LIBRARY_PATH from some default (but how does it know the
> system default?) and then calling dlopen or it could search
> the java.library.path itself, then call dlopen() with the fill
> pathname to the library itself.
Not really either of those. If java.library.path is set, then Runtime.loadLibrary() effectively prepends each path within that string to the name of the target and calls dlopen() with it; if the property is not set, it just goes with the target name and lets dlopen() have at it. Under no conditions does Runtime.loadLibrary() do any searching on its own.
Note that it's the java launcher that will set java.library.path to the value of LD_LIBRARY_PATH if the property is not specified on the command line. Only when both are null do you get the dlopen() search algorithm invoked.
- 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.
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
On 12/16/11 5:13 AM, André Warnier wrote:
> Christopher Schultz wrote:
>> -----BEGIN PGP SIGNED MESSAGE----- The issue is that the tomcat5
>> install (or a related package, or even someone manually
>> installing tcnative)
>
> It was the Debian "apt-get install tomcat5.5", I'm sure.
Are you sure? Debian is usually pretty good about using separate
packages for things like that. Looking at the "tomcat6" packages
(tomcat5.5 isn't available from the repo I'm tracking), no native
libraries are installed along with that package.
I checked, and in Lenny (where "tomcat5.5" *is* available at version
5.5.26-5lenny2), there is also no tcnative library.
Try running this from the command line:
$ dpkg -S /usr/lib/tcnative.so (or whatever the exact filename is)
That will tell you what package it came from, or it will tell you that
it's "not found" which means that it wasn't found in any installed
package. That would mean that it was installed manually by someone.
It's probably worth investigating moving that native library from
/usr/local into /path/to/tomcat5.5/bin. It will certainly make your
life (or the life of a future administrator) easier.
An aside about Tomcat in Debian:
I just checked, and on recently-built Debian Squeeze system, I can see
several packages for Tomcat 6:
tomcat6 - Servlet and JSP engine
tomcat6-user - Servlet and JSP engine -- tools to create user instances
tomcat6-common - Servlet and JSP engine -- common files
tomcat6-admin - Servlet and JSP engine -- admin web applications
tomcat6-docs - Servlet and JSP engine -- documentation
tomcat6-examples - Servlet and JSP engine -- example web applications
The "tomcat6" package contains startup scripts only for the
system-wide daemon, and depends upon "tomcat6-common" (which appears
to contain the actual "Tomcat" that we all know and love). The
"tomcat6-user" package looks like it contains those tools you'll need
to start Tomcat from the command line when not using it as a service.
The other projects seem obvious to me.
For those interested in seeing what the Debian folks have done with
their packages, here is a file listing of each package:
tomcat6:
http://packages.debian.org/squeeze/all/tomcat6/filelist
tomcat6-user:
http://packages.debian.org/squeeze/all/tomcat6-user/filelist
tomcat6-common:
http://packages.debian.org/squeeze/all/tomcat6-common/filelist
Looks like the tomcat6-user package contains some nice scripts like
"tomcat6-instance-create" which appears to automate the creation of a
CATALINA_BASE-style Tomcat instance. Someone's obviously been reading
the RUNNING.txt file :)
But I digress...
>> put the native library into /usr/lib, which is a very special
>> place. It's like someone parking their car in your "guest" space
>> -- it's rude and causes confusion, but it's not the end of the
>> world: you just have to park someplace else.
>
> Right. That's one of the much-debated inconvenients of working
> with package managers. You never quite know where they will put
> things or why. And in this case, putting it in a common place like
> /usr/lib is really debatable, since I don't think that anything
> else but Tomcat uses that library.
I'm still dubious. Looks like the "libtcnative-1" package if anything:
http://packages.debian.org/search?suite=default§ion=all&arch=any&searchon=names&keywords=tcnative
Looks like the latest version is 1.1.13 for Lenny, so it's time to
upgrade. (And if you're on Etch, like one of our aging servers, it's
REALLY time to upgrade!).
tcnative should (should!) be backward-compatible, so if you upgrade
the libtcnative-1 package to what Squeeze has available (1.1.20), then
tomcat5.5 should (should!) be okay.
>>> And finally, according to other recommendations on the list
>>> which appear to be worthy of trust, I believe that if, in the
>>> script which starts Tomcat6, I would add something like export
>>> LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH that might do
>>> the trick as far as tc-native is concerned.
>>
>> Probably, but it would be better (if possible) to move the
>> offending, outdated tcnative library into the tomcat5 deployment
>> so everyone is separate.
>
> Yes, but then "uninstall" and "upgrade" and so on won't work
> anymore..
Well, it appears that you are on a system which doesn't (yet) support
Tomcat 6 (probably Lenny or even Etch), so there is bound to be a bit
of a struggle.
>> IIRC, Tomcat loads tcnative without a version number in it's name
>> even when it prefers a version that is of a certain level. That's
>> not a great practice, but I'm not sure there's anything that can
>> be done given that evidently there have been breaking-changes
>> with non-obviously-breaking version-number bumps.
>
> Ok, so that indirectly explains another thing which I had
> separately been wondering about : why on all those *NIX systems,
> there are always a profusion of symlinks in the */lib directories,
> pointing to the same .so file, but with different names.
Yup, that's why. An application can ask the OS (okay, Chuck, the
/linker/) to load a library by it's base name (e.g. "tcnative") which
means "i don't care at all what version I get... just give me
something". Or, it can ask for "libtcnative-1" or even
"libtcnative-1.1.17". It's always best (as a program) to be as
accepting as possible, otherwise you risk failure when 1.1.17 gets
upgraded to 1.1.18. As long as they are API-compatible everything
should still work. As long as they are backward-compatible, everything
*will* work if the program requests "tcnative-1".
Now, let's say that tcnative goes to 2.0. If it is backward
compatible, you might end up with this:
libtcnative-2.0.0.so
libtcnative-2.0.so -> libtcnative-2.0.0.so
libtcnative-2.so -> libtcnative-2.0.0.so
libtcnative-1.0.so -> libtcnative-2.0.0.so
libtcnative-1.so -> libtcnative-2.0.0.so
If they're not compatible, you might end up with this (most likely
served by two separate packages, libtcnative-1 and libtcnative-2):
libtcnative-2.0.0.so
libtcnative-2.0.so -> libtcnative-2.0.0.so
libtcnative-2.so -> libtcnative-2.0.0.so
libtcnative-1.0.0.so
libtcnative-1.0.so -> libtcnative-1.0.0.so
libtcnative-1.so -> libtcnative-1.0.0.so
When an upgrade occurs to any of these packages, the most basic file
changes (in this case, libtcnative-2.0.0.so is deleted and
libtcnative-2.0.1.so is added) and the symlinks change to point to the
new version. Most programs that weren't picky about their version
number never notice the difference, which is as it should be IMO.
So, all this seems perfectly reasonable to me, but I experience
vertigo whenever I try to use CPAN. Go figure.
>>> And when native code under Linux is looking for a library, this
>>> is probably done through some other standard library providing
>>> "library loading" functions.
>>
>> This is a *NIX thing. I'm sure Microsoft Windows does things in
>> a similar way.
>
> And that's where Chuck's (so to speak) dlopen() comes in. Slowly
> the dawn comes.
It's probably unreasonable to expect that someone not familiar with
"shared objects" (or DLLs in win32-speak) -- essentially shared code
libraries -- in general to make the leap from "this program blew up
and said it couldn't find library 'x'" to reading the UNIX manual page
for "dlopen". The only clue you have is that it might say something
about LD_LIBRARY_PATH. "man LD_LIBRARY_PATH" on my Debian system has
no man page, so Google is the answer, here, unfortunately. If you read
"java.library.path" in the error message, you'll have to wade through
enough JRE documentation to know that java.library.path (a Java system
property) is essentially the same thing as LD_LIBRARY_PATH (a POSIX
environment variable) ... though I suspect that the former is
prepended to the latter for the complete picture.
I was about to say "sadly, this is one of the places where the Java
magic yields to the harsh reality of the real world" but that's only
true because native code is involved. The wool-over-the-eyes world of
Java is in-tact until you make the decision to go native, and then you
have to dodge blow-darts while running through the jungle. That's just
the Way Things Are.
>> Tomcat does not do this by default. You must explicitly
>> configure java.library.path to point to CATALINA_HOME/bin if you
>> want it to load native libraries from there.
>
> Ahaaa. /That/ was the key missing piece.
Yup -- see above for my coment re: java.library.path and LD_LIBRARY_PATH.
> So, if I compile the tc-native library, and put the resulting
> libtcnative-1.so in (catalina_home)/bin, that by itself is not
> enough to have Tomcat find it there. Right ?
Correct. *NIX systems to not, by default, use the
current-working-directory as a valid search path for binaries of any
kind. That's too risky: a rogue library sitting in "." could turn
things like 'ls' into Trojan horses. *NIX gives you enough rope to
hang yourself, but you still have to tie the noose yourself, too: it
doesn't reach-out and strangle you. Instead, you need to modify that
path in one way (LD_LIBRARY_PATH) or another (java.library.path).
Using the Java system property is *much* safer, because then the JVM
won't try to load *other* libraries from Tomcat's bin directory...
only those that you try to load from within Java itself.
> And in order for Tomcat6 to find it there, I need to do either one
> of 2 things : 1) add an option
> "-Djava.library.path=$CATALINA_HOME/bin" to the command-line that
> starts the JVM which runs Tomcat OR 2) add a line export
> LD_LIBRARY_PATH=$CATALINA_HOME/bin:$LD_LIBRARY_PATH to the script
> which starts Tomcat, prior to the actual Tomcat start line.
Yes. Stick with java.library.path.
> and 1) gives the option to the JVM, and the JVM will then pass this
> to dl_open() when it calls it
dlopen does not take a search path as a parameter -- it always uses
LD_LIBRARY_PATH.
> or 2) is something that dl_open() itself will find and add to it's
> default search path when it is called by the JVM
I'm not sure exactly how the JVM does things. It could modify it's own
environment variable by constructing LD_LIBRARY_PATH from some default
(but how does it know the system default?) and then calling dlopen or
it could search the java.library.path itself, then call dlopen() with
the fill pathname to the library itself. I suspect the latter because
I launch Tomcat with CATALINA_HOME/bin as the java.library.path and
when I check the environment in /proc/[pid]/env, I can see the
LD_LIBRARY_PATH is being set to JRE-related paths only, and doesn't
include CATALINA_HOME/bin anywhere.
> Have I got it now ?
I think so.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7rx2gACgkQ9CaO5/Lv0PDeSwCeNBTSMEv8yjO1W7wOOH5I8MZD
uycAoKp+QRKCtocHKX2DvVFclU33Cs6t
=Jjwn
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Christopher,
thanks. You provided the missing pieces.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> André,
>
> (Just discovered how to type é on my Mac's keyboard.. no more
> copy/paste for you name!)
Thanks for the effot. ;-)
It's getting better every year that passes. Until a couple of years ago, I was used to
see my name spelled as "Andr" followed by various CP-1282 graphic symbols.
>
> On 12/15/11 1:15 PM, André Warnier wrote:
>> This left me intellectually unsatisfied, because I still did not
>> know how Tomcat6 was finding this old tc-native, and there is
>> nothing really obvious in the documentation which explains where it
>> is looking. (Probably because to Real Java Programmers, this is too
>> obvious; but I am not a Real Java Programmer).
>
> This has almost nothing to do with Java... it's just the way *NIX
> loaders perform shared-library resolution.
>
>> I should add, because it seems to have a bearing here, that this
>> Tomcat6 is started by a script in /etc/init.d copied and adapted
>> from the one for Tomcat5.5, which means that it actually runs under
>> the jsvc wrapper. That may influence how the search for the
>> tc-native library is effected, and I may have to to do something to
>> tell jsvc to look in the (CATALINA_HOME)/bin directory of Tomat6
>> first. Or not, because as mentioned above, I have no idea really
>> how this all works.
>
> No, the wrapper is not relevant.
Ok, that's cleat to me now.
The issue is that the tomcat5 install
> (or a related package, or even someone manually installing tcnative)
It was the Debian "apt-get install tomcat5.5", I'm sure.
> put the native library into /usr/lib, which is a very special place.
> It's like someone parking their car in your "guest" space -- it's rude
> and causes confusion, but it's not the end of the world: you just have
> to park someplace else.
>
Right. That's one of the much-debated inconvenients of working with package managers. You
never quite know where they will put things or why.
And in this case, putting it in a common place like /usr/lib is really debatable, since I
don't think that anything else but Tomcat uses that library.
>> And finally, according to other recommendations on the list which
>> appear to be worthy of trust, I believe that if, in the script
>> which starts Tomcat6, I would add something like export
>> LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH that might do the
>> trick as far as tc-native is concerned.
>
> Probably, but it would be better (if possible) to move the offending,
> outdated tcnative library into the tomcat5 deployment so everyone is
> separate.
Yes, but then "uninstall" and "upgrade" and so on won't work anymore..
>
> IIRC, Tomcat loads tcnative without a version number in it's name even
> when it prefers a version that is of a certain level. That's not a
> great practice, but I'm not sure there's anything that can be done
> given that evidently there have been breaking-changes with
> non-obviously-breaking version-number bumps.
Ok, so that indirectly explains another thing which I had separately been wondering about
: why on all those *NIX systems, there are always a profusion of symlinks in the */lib
directories, pointing to the same .so file, but with different names.
>
>> But when I examine the environment of the running Tomcat5.5, it
>> does not seem to have LD_LIBRARY_PATH defined, so I am puzzled
>> again.
>
> Look at the man page for "ld" which ought to give you the default for
> your system. /usr/lib is certainly in there.
>
>> So let me make a partly-educated guess, and someone here can tell
>> me how far off the mark I am.
>>
>> Tomcat6 is Java code, so when it looks for a library, it actually
>> asks the JVM to find it. The JVM is native code, so it looks along
>> it's own "library path" to find the desired module. (*)
>
> Yes, but it's just a coincidence that the JVM is native :)
>
>> But the JVM being wrapped by the jsvc wrapper, it falls down to the
>> jsvc wrapper to look along its own library path for the module, in
>> an attempt to satisfy the JVM. (**)
>
> Probably not. jsvc is the parent process, so it probably dictates
> things such as environment variables, but it's not going to get
> delegated requests for library loading. That's the OS's job invoked
> directly by the JVM.
I was suspecting that, but it's nice to see it confirmed.
>
>> And when native code under Linux is looking for a library, this is
>> probably done through some other standard library providing
>> "library loading" functions.
>
> This is a *NIX thing. I'm sure Microsoft Windows does things in a
> similar way.
>
And that's where Chuck's (so to speak) dlopen() comes in.
Slowly the dawn comes.
>> And this "library loading library" probably looks first at which
>> search path is contained in the LD_LIBRARY_PATH variable, prior to
>> searching in some other path provided in it's own configuration
>> data.
>
> I think LD_LIBRARY_PATH is it. If not set, there is a default.
>
Still coming along nicely..
>> (*) but maybe Tomcat has told it to look first in CATALINA_HOME/bin
>> ? (**) or maybe jsvc does not intervene at all, and it is the JVM
>> which talks directly to the "library loading library" ?
>
> Tomcat does not do this by default. You must explicitly configure
> java.library.path to point to CATALINA_HOME/bin if you want it to load
> native libraries from there.
>
Ahaaa. /That/ was the key missing piece.
So, if I compile the tc-native library, and put the resulting libtcnative-1.so in
(catalina_home)/bin, that by itself is not enough to have Tomcat find it there.
Right ?
And in order for Tomcat6 to find it there, I need to do either one of 2 things :
1) add an option "-Djava.library.path=$CATALINA_HOME/bin" to the command-line that starts
the JVM which runs Tomcat
OR
2) add a line
export LD_LIBRARY_PATH=$CATALINA_HOME/bin:$LD_LIBRARY_PATH
to the script which starts Tomcat, prior to the actual Tomcat start line.
and
1) gives the option to the JVM, and the JVM will then pass this to dl_open() when it calls it
or
2) is something that dl_open() itself will find and add to it's default search path when
it is called by the JVM
Have I got it now ?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
André,
(Just discovered how to type é on my Mac's keyboard.. no more
copy/paste for you name!)
On 12/15/11 1:15 PM, André Warnier wrote:
> This left me intellectually unsatisfied, because I still did not
> know how Tomcat6 was finding this old tc-native, and there is
> nothing really obvious in the documentation which explains where it
> is looking. (Probably because to Real Java Programmers, this is too
> obvious; but I am not a Real Java Programmer).
This has almost nothing to do with Java... it's just the way *NIX
loaders perform shared-library resolution.
> I should add, because it seems to have a bearing here, that this
> Tomcat6 is started by a script in /etc/init.d copied and adapted
> from the one for Tomcat5.5, which means that it actually runs under
> the jsvc wrapper. That may influence how the search for the
> tc-native library is effected, and I may have to to do something to
> tell jsvc to look in the (CATALINA_HOME)/bin directory of Tomat6
> first. Or not, because as mentioned above, I have no idea really
> how this all works.
No, the wrapper is not relevant. The issue is that the tomcat5 install
(or a related package, or even someone manually installing tcnative)
put the native library into /usr/lib, which is a very special place.
It's like someone parking their car in your "guest" space -- it's rude
and causes confusion, but it's not the end of the world: you just have
to park someplace else.
> And finally, according to other recommendations on the list which
> appear to be worthy of trust, I believe that if, in the script
> which starts Tomcat6, I would add something like export
> LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH that might do the
> trick as far as tc-native is concerned.
Probably, but it would be better (if possible) to move the offending,
outdated tcnative library into the tomcat5 deployment so everyone is
separate.
IIRC, Tomcat loads tcnative without a version number in it's name even
when it prefers a version that is of a certain level. That's not a
great practice, but I'm not sure there's anything that can be done
given that evidently there have been breaking-changes with
non-obviously-breaking version-number bumps.
> But when I examine the environment of the running Tomcat5.5, it
> does not seem to have LD_LIBRARY_PATH defined, so I am puzzled
> again.
Look at the man page for "ld" which ought to give you the default for
your system. /usr/lib is certainly in there.
> So let me make a partly-educated guess, and someone here can tell
> me how far off the mark I am.
>
> Tomcat6 is Java code, so when it looks for a library, it actually
> asks the JVM to find it. The JVM is native code, so it looks along
> it's own "library path" to find the desired module. (*)
Yes, but it's just a coincidence that the JVM is native :)
> But the JVM being wrapped by the jsvc wrapper, it falls down to the
> jsvc wrapper to look along its own library path for the module, in
> an attempt to satisfy the JVM. (**)
Probably not. jsvc is the parent process, so it probably dictates
things such as environment variables, but it's not going to get
delegated requests for library loading. That's the OS's job invoked
directly by the JVM.
> And when native code under Linux is looking for a library, this is
> probably done through some other standard library providing
> "library loading" functions.
This is a *NIX thing. I'm sure Microsoft Windows does things in a
similar way.
> And this "library loading library" probably looks first at which
> search path is contained in the LD_LIBRARY_PATH variable, prior to
> searching in some other path provided in it's own configuration
> data.
I think LD_LIBRARY_PATH is it. If not set, there is a default.
> (*) but maybe Tomcat has told it to look first in CATALINA_HOME/bin
> ? (**) or maybe jsvc does not intervene at all, and it is the JVM
> which talks directly to the "library loading library" ?
Tomcat does not do this by default. You must explicitly configure
java.library.path to point to CATALINA_HOME/bin if you want it to load
native libraries from there.
> (And I am quite sure that the way I am guessing above is going to
> make some Real Programmers cringe, and wonder how I have been able
> to survive for 30+ years in this world not knowing this kind of
> stuff.)
Close Enough (tm).
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qUkUACgkQ9CaO5/Lv0PDVaQCeNCatm6T7YGB8LUfwEsnCRdcG
ZAIAniwIWVOUBx9sF5O7xh5xEkJzHREg
=yg64
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Gregor S. wrote:
> Hi Chuck!
>
> On Thu, Dec 15, 2011 at 5:36 PM, Caldarale, Charles R
> <Ch...@unisys.com> wrote:
>>> From: Gregor S. [mailto:rc46fi@googlemail.com]
>>> Subject: Re: path used for tc-natuve
>>> I guess it's a bad idea to run two different versions
>>> of Tomcat on the same box.
>> ??? Clearly that's not true - it's done all the time. Much easier when not using these 3rd-party repackaged corruptions...
>
> Hm, maybe my view is too limited, but I really can't see any good
> reason running two different versions on the same box.
>
> What's the user-story behind this configuration?
>
Actually, it is like this : my company is, among other things, hosting application servers
on behalf of others. Think Amazon or Google, just a bit smaller. Quite a bit smaller in
fact. Ok, 0.00001 times smaller or so.
Anyway, we have a Linux server which we host on behalf of a software & services company,
for the ultimate benefit of one of their customers. This server runs Tomcat 5.5, also as a
small intermediate component between the user's workstation and the final application,
wich itself runs under a separate software.
Recently, there have been some communications issues between the workstations and the
application, with both mod_jk and Tomcat 5.5 indicating some errors in their respective
logs. And the software company searched Google and found some indications that a more
recent version of Tomcat might help alleviate the issue, and could we please install a
Tomcat 6.0 on this machine to verify if that's true.
The idea being to be able to temporarily switch just between Tomcat 5.5 and Tomcat 6.0, to
see if the problem disappears, but be able to switch back to Tomcat 5.5 quickly if it does
not or gets worse.
Being the helpful people that we are, we set things in motion immediately to satisfy our
customer.
The software running on that system is installed entirely using the Debian software
package manager (dpkg, apt and consorts). And for that version of Linux, there is no
Tomcat6 package available. Never mind, according to Plan B we downloaded and installed an
official Tomcat from the website. However, when we switched over to that Tomcat6, it
started producing ugly messages in the log indicating that the tc-native version that it
found was outdated, and that it needed at least version so and so.
Which was traced to the fact that it was finding the tc-native library installed by the
Tomcat 5.5 package, in /usr/lib, and not liking the looks of it.
We cannot de-install Tomcat 5.5 nor its older tc-native.
So I was looking for a way either to just stop Tomcat 6 from looking for tc-native, or of
installing the appropriate tc-native somewhere where Tomcat 6 would find it, along
whatever path it is looking for it, prior to the old version in /usr/lib.
With help from the list, I managed to stop it looking for tc-native, by disabling the
<Listener> in server.xml. That made at least the ugly message disappear, and for a test it
is ok to run with the standard Java-based socket stuff. Plan C is thus succesfully
implemented and everyone is happy, except me.
This left me intellectually unsatisfied, because I still did not know how Tomcat6 was
finding this old tc-native, and there is nothing really obvious in the documentation which
explains where it is looking. (Probably because to Real Java Programmers, this is too
obvious; but I am not a Real Java Programmer).
So that's where this very Tomcat list comes in handy again.
Through the information obtained on it, I think I have learned
- that I can compile tc-native if I just have OpenSSL installed on the system (which I have)
- that if I do compile tc-native and install the resulting tc-native library in the
(CATALINA_HOME)/bin directory of Tomat6, it should use it , by preference to the one in
/usr/lib.
I still don't know exactly why though, and this lack of knowledge is just killing me.
I should add, because it seems to have a bearing here, that this Tomcat6 is started by a
script in /etc/init.d copied and adapted from the one for Tomcat5.5, which means that it
actually runs under the jsvc wrapper.
That may influence how the search for the tc-native library is effected, and I may have to
to do something to tell jsvc to look in the (CATALINA_HOME)/bin directory of Tomat6 first.
Or not, because as mentioned above, I have no idea really how this all works.
And finally, according to other recommendations on the list which appear to be worthy of
trust, I believe that if, in the script which starts Tomcat6, I would add something like
export LD_LIBRARY_PATH=/opt/tomcat6/bin:$LD_LIBRARY_PATH
that might do the trick as far as tc-native is concerned.
But when I examine the environment of the running Tomcat5.5, it does not seem to have
LD_LIBRARY_PATH defined, so I am puzzled again.
So let me make a partly-educated guess, and someone here can tell me how far off the mark
I am.
Tomcat6 is Java code, so when it looks for a library, it actually asks the JVM to find it.
The JVM is native code, so it looks along it's own "library path" to find the desired
module. (*)
But the JVM being wrapped by the jsvc wrapper, it falls down to the jsvc wrapper to look
along its own library path for the module, in an attempt to satisfy the JVM. (**)
And when native code under Linux is looking for a library, this is probably done through
some other standard library providing "library loading" functions.
And this "library loading library" probably looks first at which search path is contained
in the LD_LIBRARY_PATH variable, prior to searching in some other path provided in it's
own configuration data.
(*) but maybe Tomcat has told it to look first in CATALINA_HOME/bin ?
(**) or maybe jsvc does not intervene at all, and it is the JVM which talks directly to
the "library loading library" ?
(And I am quite sure that the way I am guessing above is going to make some Real
Programmers cringe, and wonder how I have been able to survive for 30+ years in this world
not knowing this kind of stuff.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by "Gregor S." <rc...@googlemail.com>.
Hi Chuck!
On Thu, Dec 15, 2011 at 5:36 PM, Caldarale, Charles R
<Ch...@unisys.com> wrote:
>> From: Gregor S. [mailto:rc46fi@googlemail.com]
>> Subject: Re: path used for tc-natuve
>
>> I guess it's a bad idea to run two different versions
>> of Tomcat on the same box.
>
> ??? Clearly that's not true - it's done all the time. Much easier when not using these 3rd-party repackaged corruptions...
Hm, maybe my view is too limited, but I really can't see any good
reason running two different versions on the same box.
What's the user-story behind this configuration?
Actually, I can only think of three:
- shared hosting, where each customer gets his own Tomcat instance
Well, I guess shared hosting is dead anyways, since if you're running
a serious business: Go and get your own server - they don't cost that
much
- Using 3rd party software which is bound to a certain version of a
certain servlet-container
Well, in this case, you've bought the wrong software. When we are
evaluating software, and a provider tells us that he needs a certain
version of Tomcat / Java / Windows / IE / ... , he can grab his stuff,
and we wish him well.
- upgrading Tomcat and keeping the old version - just in case...
Again: In times of virtualization, I have the production-machine as a
VM on my laptop. I'm testing and developing there, and once it's
ready, just put the image on a "real" test-server.
After successful testing, the image is propagated to the
production-server, meaning old Tomcat is gone.
Still, I can see no serious reason why somebody should ask for trouble
& run two different Tomcat-version on one box - sorry.
Still, you're invited to enlighten me ;)
Cheers
Gregor
--
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Gregor S. [mailto:rc46fi@googlemail.com]
> Subject: Re: path used for tc-natuve
> I guess it's a bad idea to run two different versions
> of Tomcat on the same box.
??? Clearly that's not true - it's done all the time. Much easier when not using these 3rd-party repackaged corruptions...
- 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.
Re: path used for tc-natuve
Posted by "Gregor S." <rc...@googlemail.com>.
...and sorry for my typoes, I'm kind in a rush...
--
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by "Gregor S." <rc...@googlemail.com>.
Hi Chris,
On Thu, Dec 15, 2011 at 4:34 PM, Christopher Schultz
<ch...@christopherschultz.net> wrote:
>
> I think that's a bad idea because then you have built your libtcnative
> (which can be considered Tomcat-version-specific, or at least
> Tomcat-version-sensitive) for the whole system to use and that
> essentially locks you into that version regardless of Tomcat version
> being run at the time.
True. However, I guess it's a bad idea to run two different versions
of Tomcat on the same box.
I don't know Andre's motivation for installing TC6, but I assumed
(maybe wrongly) that he wanted to replace the old version.
Howver, there's a pretty solution even when running two different
versions on the same box:
When compiling, libtcnative goes to
$CATALINA_HOME//bin/tomcat-native-1.1.20-src/jni/native/.lib
(dpeneding on the tomcat-native-version).
So instead of putting it inti /usr/lib, leave it at the original place
and just change the CATALAINA_OPTS accordingly.
Cheers!
Gregor
--
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Gregor,
On 12/15/11 8:34 AM, Gregor S. wrote:
> And as mentioned in the thread here, you'll have to change your
> LD-LIBRARY_PATH, so that it contains tcnative.
>
> In my environment here, I just adapted the CTALINA_OPTS inside the
> startup-script:
>
> CATALINA_OPTS="$JPDA_OPTS -XX:MaxPermSize=384m -Xmx2048m -Xms2048m
> -Djava.library.path=/usr/lib"
- -1
I think that's a bad idea because then you have built your libtcnative
(which can be considered Tomcat-version-specific, or at least
Tomcat-version-sensitive) for the whole system to use and that
essentially locks you into that version regardless of Tomcat version
being run at the time. You end up in the situation where André is:
libtcnative is being found when he doesn't want it to be found. You
can't really remove /usr/lib from the LD_LIBRARY_PATH or nothing
works. Your only recourse it to disable the APR Listener.
> And /usr/lib is where you put libtcnative after using libtool as
> recommended in the BUILDING.TXT:
Fortunately, neither current trunk nor current release (1.1.22) does
not recommend installing libtcnative in /usr/lib.
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7qE5cACgkQ9CaO5/Lv0PBXaACfaUNSIB5po0TpdyVV4N/NXdvH
zzcAnR0G0XzKtFQTtmf+L0agMWEH52zX
=BISx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by "Gregor S." <rc...@googlemail.com>.
Hi André,
On Thu, Dec 15, 2011 at 3:45 PM, André Warnier <aw...@ice-sa.com> wrote:
>
> Indeed. Where have you been ?
>
either in the office or changing Junior's nappies ;)
> I am not using HTTPS, and my problem is not at the /running/ stage.
> But from the README, I got the impression that I needed OpenSSL in order to
> /compile/ tc-native. I tool "OpenSSL" to mean "the OpenSSL sources" or "the
> OpenSSL headers" or ksomething of the kind, and that's when I gave up.
> I didn't really read any further, I must admit.
Well, you don't have to use OpenSSL unless you're running https..
Still, if you have OpenSSL installed, compiling is a walk in the park,
and installing OpenSSL is merley a call of apt-get.
Then, just enter
./configure --with-apr=/usr/bin/apr-1-config --with-ssl=/usr/lib/
--with-java-home=$JAVA_HOME
After that, make && make install, and you're all set.
Since I'm running the same configs here (Debian, Tomcat6, APR & jsvc),
feel free to drop me a line, maybe I can be of some help ;)
Cheers!
Gregor
--
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Gregor S. wrote:
> Hi André,
Hi Gregor.
>
> long time no see ;)
Indeed. Where have you been ?
...
>
> You'l only need OpenSSL if you are running a https-connector. if you
> don't use https, you don't need OpenSSL.
>
I am not using HTTPS, and my problem is not at the /running/ stage.
But from the README, I got the impression that I needed OpenSSL in order to /compile/
tc-native. I tool "OpenSSL" to mean "the OpenSSL sources" or "the OpenSSL headers" or
ksomething of the kind, and that's when I gave up.
I didn't really read any further, I must admit.
I am not really rational about those things anymore, ever since about a year ago having to
install something at a customer's site under RHEL and under tight security and tight time
constraints, with 3 sysadmins looking over my shoulder, and every damn rpm needing to be
pre-approved by a team of at least 15 people...
So when I see a phrase like "You may need.." it kind of turns me off, if it is something
that I do not absolutely need to do.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by "Gregor S." <rc...@googlemail.com>.
Hi André,
long time no see ;)
Ok, let's try to free you from your wprries:
You'l only need OpenSSL if you are running a https-connector. if you
don't use https, you don't need OpenSSL.
And even if you want to run https, it's no big deal:
apt-get install OpenSSL
and you're all set.
One question still, for which I couldn't find an answer within this thread:
You did compile tcnative for Tomcat6, right?
And as mentioned in the thread here, you'll have to change your
LD-LIBRARY_PATH, so that it contains tcnative.
In my environment here, I just adapted the CTALINA_OPTS inside the
startup-script:
CATALINA_OPTS="$JPDA_OPTS -XX:MaxPermSize=384m -Xmx2048m -Xms2048m
-Djava.library.path=/usr/lib"
And /usr/lib is where you put libtcnative after using libtool as
recommended in the BUILDING.TXT:
dekolxrd13:/opt/apache-tomcat-6.0.33/bin# ls -l /usr/lib/libtcn*
-rw-r--r-- 1 root root 1116156 1. Dez 19:05 /usr/lib/libtcnative-1.a
-rwxr-xr-x 1 root root 928 1. Dez 19:05 /usr/lib/libtcnative-1.la
lrwxrwxrwx 1 root root 23 1. Dez 19:05 /usr/lib/libtcnative-1.so
-> libtcnative-1.so.0.1.20
lrwxrwxrwx 1 root root 23 1. Dez 19:05
/usr/lib/libtcnative-1.so.0 -> libtcnative-1.so.0.1.20
-rwxr-xr-x 1 root root 790332 1. Dez 19:05 /usr/lib/libtcnative-1.so.0.1.20
HTH
Gregor
On Wed, Dec 14, 2011 at 8:57 AM, André Warnier <aw...@ice-sa.com> wrote:
> Christopher Schultz wrote:
>>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> Chuck,
>>
>> On 12/12/11 8:27 PM, Caldarale, Charles R wrote:
>>>>
>>>> From: André Warnier [mailto:aw@ice-sa.com] Subject: Re: path used
>>>> for tc-natuve
>>>> And if I do this, where do I put the result, in such a way that it
>>>> doesn't overwrite the existing one used by tomcat5.5 ?
>>>
>>> One would normally place it in Tomcat's bin directory, and set
>>> LD_LIBRARY_PATH or -Djava.library.path to point there. It's a bit
>>> scary (and rude) to put it in a public place.
>>
>>
>> +1
>>
>> I think Andre's original problem wasn't with tcnative, but with
>> libapr. If you build the new tcnative dynamically-linked, then you're
>> going to have the same problem.
>>
>> Other possibilities include building everything (libapr and
>> libtcnative) and putting them into, say, CATALINA_HOME/bin. I recently
>> had a fun (read: miserable) time doing this with 2 versions of each
>> (total of 4 possibilities) along with 2 libssl versions at the same
>> time. Trying to trump the system-level libraries requires that you
>> cover all your bases, otherwise some library name (like
>> libapr.1.4.2.so) will not override /usr/lib/libapr.1.so. Make sure
>> you've got all your symlinks right :)
>>
>
> Well, yes. And that's exactly why, for the time being, I have decided to do
> without tc-native. The first line I saw in the tc-native source README was
> something like "to build, you may need OpenSSL xx .." and then I started
> getting cold feet, remembering my previous experiences going along the
> dependencies-from-hell route umpteen times before.
> And in this case, we're talking indeed about a system which already has all
> those nice symlinks all over the place..
> What is it he said ? "once you give in to the dark side of the Force,
> forever dominate you it will.."
> If apt-get is the dark side, then I guess I'm already on Darth's side.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
just because you're paranoid, don't mean they're not after you...
gpgp-fp: 3DB13F197F8A0360814885D1F1F1E2EFAD509AFD
skype:rc46fi
gplus.to/gregor
twitter.com/#/2smart4u
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Christopher Schultz wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Chuck,
>
> On 12/12/11 8:27 PM, Caldarale, Charles R wrote:
>>> From: André Warnier [mailto:aw@ice-sa.com] Subject: Re: path used
>>> for tc-natuve
>>> And if I do this, where do I put the result, in such a way that
>>> it doesn't overwrite the existing one used by tomcat5.5 ?
>> One would normally place it in Tomcat's bin directory, and set
>> LD_LIBRARY_PATH or -Djava.library.path to point there. It's a bit
>> scary (and rude) to put it in a public place.
>
> +1
>
> I think Andre's original problem wasn't with tcnative, but with
> libapr. If you build the new tcnative dynamically-linked, then you're
> going to have the same problem.
>
> Other possibilities include building everything (libapr and
> libtcnative) and putting them into, say, CATALINA_HOME/bin. I recently
> had a fun (read: miserable) time doing this with 2 versions of each
> (total of 4 possibilities) along with 2 libssl versions at the same
> time. Trying to trump the system-level libraries requires that you
> cover all your bases, otherwise some library name (like
> libapr.1.4.2.so) will not override /usr/lib/libapr.1.so. Make sure
> you've got all your symlinks right :)
>
Well, yes. And that's exactly why, for the time being, I have decided to do without
tc-native. The first line I saw in the tc-native source README was something like "to
build, you may need OpenSSL xx .." and then I started getting cold feet, remembering my
previous experiences going along the dependencies-from-hell route umpteen times before.
And in this case, we're talking indeed about a system which already has all those nice
symlinks all over the place..
What is it he said ? "once you give in to the dark side of the Force, forever dominate you
it will.."
If apt-get is the dark side, then I guess I'm already on Darth's side.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Christopher Schultz <ch...@christopherschultz.net>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Chuck,
On 12/12/11 8:27 PM, Caldarale, Charles R wrote:
>> From: André Warnier [mailto:aw@ice-sa.com] Subject: Re: path used
>> for tc-natuve
>
>> And if I do this, where do I put the result, in such a way that
>> it doesn't overwrite the existing one used by tomcat5.5 ?
>
> One would normally place it in Tomcat's bin directory, and set
> LD_LIBRARY_PATH or -Djava.library.path to point there. It's a bit
> scary (and rude) to put it in a public place.
+1
I think Andre's original problem wasn't with tcnative, but with
libapr. If you build the new tcnative dynamically-linked, then you're
going to have the same problem.
Other possibilities include building everything (libapr and
libtcnative) and putting them into, say, CATALINA_HOME/bin. I recently
had a fun (read: miserable) time doing this with 2 versions of each
(total of 4 possibilities) along with 2 libssl versions at the same
time. Trying to trump the system-level libraries requires that you
cover all your bases, otherwise some library name (like
libapr.1.4.2.so) will not override /usr/lib/libapr.1.so. Make sure
you've got all your symlinks right :)
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAk7nrvwACgkQ9CaO5/Lv0PDLxACgsIQ7uFeOEu9SIHtoITdLPHLR
X/gAn2K3lCTB/pB5zBwyc2s7sTnlxcVU
=O+fe
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: path used for tc-natuve
> And if I do this, where do I put the result, in such a way that
> it doesn't overwrite the existing one used by tomcat5.5 ?
One would normally place it in Tomcat's bin directory, and set LD_LIBRARY_PATH or -Djava.library.path to point there. It's a bit scary (and rude) to put it in a public place.
> > If you don't want to use it, then comment out the Listener at the
> > start of server.xml.
> You mean this one ?
> <Listener className="org.apache.catalina.core.AprLifecycleListener" />
That's the one.
- 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.
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Pid wrote:
...
>
>
> It's often found under /usr/lib/apr or /usr/local/apr.
>
>
> You could just build the new version from the one in tomcat/bin.
And if I do this, where do I put the result, in such a way that it doesn't overwrite the
existing one used by tomcat5.5 ?
Or is that in the on-line docs ?
>
> If you don't want to use it, then comment out the Listener at the start
> of server.xml.
>
You mean this one ?
<Listener className="org.apache.catalina.core.AprLifecycleListener" />
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Pid <pi...@pidster.com>.
On 12/12/2011 22:25, André Warnier wrote:
> Pid * wrote:
>> On 12 Dec 2011, at 16:37, "André Warnier" <aw...@ice-sa.com> wrote:
>>
>>> Hi
>>>
>>> On a Debian Linux system, was running a Debian-pre-packaged Tomcat 5.5.
>>> We stopped this Tomcat 5.5, but did not remove the corresponding
>>> package(s).
>>> Then we installed an "official" Tomcat 6, downloaded from the Tomcat
>>> website, in /opt/tomcat6 as "CATALINA_HOME".
>>> We then made a copy of the /etc/init.d startup script which used to
>>> start Tomcat 5.5, and modified it to start this new Tomcat6 instead.
>>>
>>> Now when stopping and starting this Tomcat6, we are getting the
>>> message below (about APR) in the Tomcat6 logfile.
>>>
>>> My question is : where could Tomcat6 find this APR tc-native of the
>>> wrong version ?
>>> As far as I can tell, there is no unpacked tc-native anything in the
>>> Tomcat6 directories.
>>
>> $LD_LIBRARY_PATH
>>
>> Or check the -Djava.library.path set by the script.
>>
>>
>
> Francis, thanks for the perl tip.
> Pid, see following data.
>
> 1) these are the tomcat6 processes, as shown by "ps" :
> (sorry for the format, I hope it is readable)
>
> root 21245 1 0 21:19 ? 00:00:00 /usr/bin/jsvc -user
> tomcat55 -cp
> /usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar
> -outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
> -Djava.awt.headless=true -Xms256M -Xmx256M
> -Djava.endorsed.dirs=/opt/tomcat6/common/endorsed
> -Dcatalina.base=/opt/tomcat6 -Dcatalina.home=/opt/tomcat6
> -Djava.io.tmpdir=/opt/tomcat6/temp
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
> org.apache.catalina.startup.Bootstrap
>
> root 21246 21245 0 21:19 ? 00:00:00 /usr/bin/jsvc -user
> tomcat55 -cp
> /usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar
> -outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
> -Djava.awt.headless=true -Xms256M -Xmx256M
> -Djava.endorsed.dirs=/opt/tomcat6/common/endorsed
> -Dcatalina.base=/opt/tomcat6 -Dcatalina.home=/opt/tomcat6
> -Djava.io.tmpdir=/opt/tomcat6/temp
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
> org.apache.catalina.startup.Bootstrap
>
> tomcat55 21247 21245 15 21:19 ? 00:00:01 /usr/bin/jsvc -user
> tomcat55 -cp
> /usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar
> -outfile SYSLOG -errfile SYSLOG -pidfile /var/run/tomcat6.pid
> -Djava.awt.headless=true -Xms256M -Xmx256M
> -Djava.endorsed.dirs=/opt/tomcat6/common/endorsed
> -Dcatalina.base=/opt/tomcat6 -Dcatalina.home=/opt/tomcat6
> -Djava.io.tmpdir=/opt/tomcat6/temp
> -Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
> -Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
> org.apache.catalina.startup.Bootstrap
>
> and this is the output for Francis' one-liner :
>
> # perl -ple 's,\00,\n,g' /proc/21245/environ
> SHELL=/bin/bash
> TERM=xterm
> SSH_CLIENT=84.158.8.209 1689 22
> JSSE_HOME=/usr/lib/jvm/java-6-sun/jre/
> SSH_TTY=/dev/pts/0
> USER=root
> LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=0
0
>
> ;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:
> PATH=/bin:/usr/bin:/sbin:/usr/sbin
> MAIL=/var/mail/root
> PWD=/opt/tomcat6/temp
> JAVA_HOME=/usr/lib/jvm/java-6-sun
> LANG=en_US.UTF-8
> HOME=/root
> SHLVL=2
> LS_OPTIONS=--color=auto
> LOGNAME=root
> SSH_CONNECTION=84.158.8.209 1689 212.85.38.202 22
> EFSDIR=/mnt/NAS/MIRA/EFS
> LC_CTYPE=de_DE.iso885915@euro
> _=/usr/bin/jsvc
> OLDPWD=/root
>
> (I picked the first of the above processes)
>
> Thus, it does not seem that there is either a $LD_LIBRARY_PATH set, nor
> an explicit "-Djava.library.path" on the tomcat (or jsvc) command-line.
> (Or I am missing something).
>
> So then, to repeat the question, where might this Tomcat Native library
> be, which Tomcat finds and is complaining about ?
>
> Here follows a list of files from the tomcat6 installation dir. Apart
> from tomcat-native.tar.gz, I don't see anything there which looks like a
> tc-native library..
>
> v2:/opt/tomcat6# ls -l
> total 63
> drwxrwxr-x 2 root root 1024 2011-12-09 16:33 bin
> drwxr-xr-x 4 tomcat55 adm 1024 2011-12-12 21:19 conf
> drwxr-xr-x 2 root root 1024 2011-12-09 12:02 lib
> -rw-r--r-- 1 root root 37951 2011-11-28 11:22 LICENSE
> drwxr-xr-x 2 tomcat55 adm 1024 2011-12-12 19:17 logs
> -rw-r--r-- 1 root root 558 2011-11-28 11:22 NOTICE
> -rw-r--r-- 1 root root 8680 2011-11-28 11:20 RELEASE-NOTES
> -rw-r--r-- 1 root root 6670 2011-11-28 11:22 RUNNING.txt
> drwxr-xr-x 2 tomcat55 root 1024 2011-12-09 16:10 temp
> lrwxrwxrwx 1 root root 26 2011-12-09 15:01 webapps ->
> /var/lib/tomcat5.5/webapps
> drwxr-xr-x 7 root root 1024 2011-11-28 11:20 webapps.orig
> drwxr-xr-x 3 tomcat55 adm 1024 2011-12-09 17:08 work
> v2:/opt/tomcat6# ls -l bin
> total 596
> -rw-r--r-- 1 star star 22705 2011-11-28 11:20 bootstrap.jar
> -rw-r--r-- 1 star star 11830 2011-11-28 11:20 catalina.bat
> -rwxr-xr-x 1 star star 17708 2011-11-28 11:20 catalina.sh
> -rw-r--r-- 1 star star 2374 2011-11-28 11:20 catalina-tasks.xml
> -rw-r--r-- 1 star star 24172 2011-11-28 11:20 commons-daemon.jar
> -rw-r--r-- 1 star star 199623 2011-11-28 11:20 commons-daemon-native.tar.gz
> -rw-r--r-- 1 star star 1342 2011-11-28 11:20 cpappend.bat
> -rw-r--r-- 1 star star 2108 2011-11-28 11:20 digest.bat
> -rwxr-xr-x 1 star star 1689 2011-11-28 11:20 digest.sh
> -rw-r--r-- 1 star star 3150 2011-11-28 11:20 setclasspath.bat
> -rwxr-xr-x 1 star star 4114 2011-11-28 11:20 setclasspath.sh
> -rw-r--r-- 1 star star 2108 2011-11-28 11:20 shutdown.bat
> -rwxr-xr-x 1 star star 1628 2011-11-28 11:20 shutdown.sh
> -rw-r--r-- 1 star star 2109 2011-11-28 11:20 startup.bat
> -rwxr-xr-x 1 star star 2023 2011-11-28 11:20 startup.sh
> -rw-r--r-- 1 star star 32277 2011-11-28 11:20 tomcat-juli.jar
> -rw-r--r-- 1 star star 249259 2011-11-28 11:20 tomcat-native.tar.gz
> -rw-r--r-- 1 star star 3479 2011-11-28 11:20 tool-wrapper.bat
> -rwxr-xr-x 1 star star 3472 2011-11-28 11:20 tool-wrapper.sh
> -rw-r--r-- 1 star star 2113 2011-11-28 11:20 version.bat
> -rwxr-xr-x 1 star star 1632 2011-11-28 11:20 version.sh
> v2:/opt/tomcat6# find . -name tomcat-native*
> ./bin/tomcat-native.tar.gz
> v2:/opt/tomcat6# find . -name tc*
> v2:/opt/tomcat6#
It's often found under /usr/lib/apr or /usr/local/apr.
You could just build the new version from the one in tomcat/bin.
If you don't want to use it, then comment out the Listener at the start
of server.xml.
p
>>> Dec 12, 2011 12:37:14 PM org.apache.coyote.http11.Http11Protocol destroy
>>> INFO: Stopping Coyote HTTP/1.1 on http-8180
>>> 12.12.2011 12:37:24 org.apache.catalina.core.AprLifecycleListener init
>>> SCHWERWIEGEND: An incompatible version 1.1.12 of the APR based Apache
>>> Tomcat Native library is installed, while Tomcat requires version 1.1.17
>>> 12.12.2011 12:37:24 org.apache.coyote.http11.Http11Protocol init
>>> INFO: Initializing Coyote HTTP/1.1 on http-8180
>>> 12.12.2011 12:37:24 org.apache.catalina.startup.Catalina load
>>> INFO: Initialization processed in 2079 ms
>>> 12.12.2011 12:37:26 org.apache.catalina.core.StandardService start
>>> INFO: Starting service Catalina
>>> 12.12.2011 12:37:26 org.apache.catalina.core.StandardEngine start
>>> INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
>>> 12.12.2011 12:37:26 org.apache.catalina.startup.HostConfig
>>> deployDirectory
>>> INFO: Deploying web application directory test
>>> 12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig
>>> deployDirectory
>>> INFO: Deploying web application directory dumpuser
>>> 12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig
>>> deployDirectory
>>> INFO: Deploying web application directory starweb
>>> 12.12.2011 12:37:27 org.apache.coyote.http11.Http11Protocol start
>>> INFO: Starting Coyote HTTP/1.1 on http-8180
>>> 12.12.2011 12:37:27 org.apache.jk.common.ChannelSocket init
>>> INFO: JK: ajp13 listening on /0.0.0.0:8009
>>> 12.12.2011 12:37:27 org.apache.jk.server.JkMain start
>>> INFO: Jk running ID=0 time=0/55 config=null
>>> 12.12.2011 12:37:27 org.apache.catalina.startup.Catalina start
>>> INFO: Server startup in 2993 ms
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: users-help@tomcat.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
--
[key:62590808]
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: path used for tc-natuve
> it does not seem that there is either a $LD_LIBRARY_PATH set, nor an
> explicit "-Djava.library.path" on the tomcat (or jsvc) command-line.
> So then, to repeat the question, where might this Tomcat Native library
> be, which Tomcat finds and is complaining about ?
I wonder if dlopen() is defaulting to the ldconfig list? Look in /etc/ld.so.conf for that.
- 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.
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: André Warnier [mailto:aw@ice-sa.com]
> Subject: Re: path used for tc-natuve
> which still does not really explain (to me) why Tomcat
> looks for it there. Or is it jsvc ?
Neither - it's the Linux dynamic loader, required to do so by the Linux API contract for dlopen().
> So how do I install a version of tcnative which will satisfy
> Tomcat6 (which lives in /opt/tomcat6), in such a way that
> Tomcat6 will find it before the ones listed above ?
Put it in Tomcat's bin directory. I would also remove the obnoxiously-placed older version, and place that in Tomcat 5.5's bin directory - assuming you can find it, given the corruption caused by installing ill-conceived 3rd party repackaged versions :-)
> will this new version of tcnative be happy with the current
> Apache APR library which is also on that system ?
Shouldn't matter, since a real tcnative-1 from tomcat.apached.org is self-contained; use ldd to make sure. Don't know what dependencies the 3rd-party versions might have.
- 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.
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Caldarale, Charles R wrote:
>> From: Caldarale, Charles R
>> Subject: RE: path used for tc-natuve
>
>>> So then, to repeat the question, where might this Tomcat Native
>>> library be, which Tomcat finds and is complaining about ?
>
>> I wonder if dlopen() is defaulting to the ldconfig list? Look in
>> /etc/ld.so.conf for that.
>
> According to the man page for dlopen(), /lib and /usr/lib are also searched, so the .so file might be hiding there.
>
Yep :
v2:/usr/lib# ls -l libtc*
-rw-r--r-- 1 root root 244964 2008-06-12 22:18 libtcnative-1.a
-rw-r--r-- 1 root root 901 2008-06-12 22:18 libtcnative-1.la
lrwxrwxrwx 1 root root 23 2011-04-13 08:40 libtcnative-1.so -> libtcnative-1.so.0.1.12
lrwxrwxrwx 1 root root 23 2011-04-13 08:40 libtcnative-1.so.0 -> libtcnative-1.so.0.1.12
-rw-r--r-- 1 root root 152008 2008-06-12 22:18 libtcnative-1.so.0.1.12
which still does not really explain (to me) why Tomcat looks for it there. Or is it jsvc ?
And another question then :
So one version of tcnative is thus in /usr/lib, and it is the version that was installed
with tomcat5.5, which is still on the machine. And Tomcat6 also finds it, through whatever
means. And it complains about it, because it is too old. But Tomcat5.5 is happy with it,
and I want to keep Tomcat5.5 at least runnable for now, until I have Tomcat6 totally
sorted out.
So how do I install a version of tcnative which will satisfy Tomcat6 (which lives in
/opt/tomcat6), in such a way that Tomcat6 will find it before the ones listed above ?
And, will this new version of tcnative be happy with the current Apache APR library which
is also on that system ? Or does it not use it ?
To wit :
v2:/usr/lib# ls -l libapr*
lrwxrwxrwx 1 root root 18 2011-05-23 22:19 libapr-1.so.0 -> libapr-1.so.0.2.12
-rw-r--r-- 1 root root 213512 2011-05-19 08:24 libapr-1.so.0.2.12
lrwxrwxrwx 1 root root 18 2011-01-01 19:47 libapreq2.so.3 -> libapreq2.so.3.6.0
-rw-r--r-- 1 root root 53096 2008-05-04 12:12 libapreq2.so.3.6.0
lrwxrwxrwx 1 root root 22 2010-12-31 14:59 libaprutil-1.so.0 -> libaprutil-1.so.0.2.12
-rw-r--r-- 1 root root 143912 2010-10-01 18:39 libaprutil-1.so.0.2.12
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
RE: path used for tc-natuve
Posted by "Caldarale, Charles R" <Ch...@unisys.com>.
> From: Caldarale, Charles R
> Subject: RE: path used for tc-natuve
> > So then, to repeat the question, where might this Tomcat Native
> > library be, which Tomcat finds and is complaining about ?
> I wonder if dlopen() is defaulting to the ldconfig list? Look in
> /etc/ld.so.conf for that.
According to the man page for dlopen(), /lib and /usr/lib are also searched, so the .so file might be hiding there.
- 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.
Re: path used for tc-natuve
Posted by André Warnier <aw...@ice-sa.com>.
Pid * wrote:
> On 12 Dec 2011, at 16:37, "André Warnier" <aw...@ice-sa.com> wrote:
>
>> Hi
>>
>> On a Debian Linux system, was running a Debian-pre-packaged Tomcat 5.5.
>> We stopped this Tomcat 5.5, but did not remove the corresponding package(s).
>> Then we installed an "official" Tomcat 6, downloaded from the Tomcat website, in /opt/tomcat6 as "CATALINA_HOME".
>> We then made a copy of the /etc/init.d startup script which used to start Tomcat 5.5, and modified it to start this new Tomcat6 instead.
>>
>> Now when stopping and starting this Tomcat6, we are getting the message below (about APR) in the Tomcat6 logfile.
>>
>> My question is : where could Tomcat6 find this APR tc-native of the wrong version ?
>> As far as I can tell, there is no unpacked tc-native anything in the Tomcat6 directories.
>
> $LD_LIBRARY_PATH
>
> Or check the -Djava.library.path set by the script.
>
>
Francis, thanks for the perl tip.
Pid, see following data.
1) these are the tomcat6 processes, as shown by "ps" :
(sorry for the format, I hope it is readable)
root 21245 1 0 21:19 ? 00:00:00 /usr/bin/jsvc -user tomcat55 -cp
/usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar -outfile SYSLOG -errfile
SYSLOG -pidfile /var/run/tomcat6.pid -Djava.awt.headless=true -Xms256M -Xmx256M
-Djava.endorsed.dirs=/opt/tomcat6/common/endorsed -Dcatalina.base=/opt/tomcat6
-Dcatalina.home=/opt/tomcat6 -Djava.io.tmpdir=/opt/tomcat6/temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
org.apache.catalina.startup.Bootstrap
root 21246 21245 0 21:19 ? 00:00:00 /usr/bin/jsvc -user tomcat55 -cp
/usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar -outfile SYSLOG -errfile
SYSLOG -pidfile /var/run/tomcat6.pid -Djava.awt.headless=true -Xms256M -Xmx256M
-Djava.endorsed.dirs=/opt/tomcat6/common/endorsed -Dcatalina.base=/opt/tomcat6
-Dcatalina.home=/opt/tomcat6 -Djava.io.tmpdir=/opt/tomcat6/temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
org.apache.catalina.startup.Bootstrap
tomcat55 21247 21245 15 21:19 ? 00:00:01 /usr/bin/jsvc -user tomcat55 -cp
/usr/share/java/commons-daemon.jar:/opt/tomcat6/bin/bootstrap.jar -outfile SYSLOG -errfile
SYSLOG -pidfile /var/run/tomcat6.pid -Djava.awt.headless=true -Xms256M -Xmx256M
-Djava.endorsed.dirs=/opt/tomcat6/common/endorsed -Dcatalina.base=/opt/tomcat6
-Dcatalina.home=/opt/tomcat6 -Djava.io.tmpdir=/opt/tomcat6/temp
-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager
-Djava.util.logging.config.file=/opt/tomcat6/conf/logging.properties
org.apache.catalina.startup.Bootstrap
and this is the output for Francis' one-liner :
# perl -ple 's,\00,\n,g' /proc/21245/environ
SHELL=/bin/bash
TERM=xterm
SSH_CLIENT=84.158.8.209 1689 22
JSSE_HOME=/usr/lib/jvm/java-6-sun/jre/
SSH_TTY=/dev/pts/0
USER=root
LS_COLORS=no=00:fi=00:di=01;34:ln=01;36:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.svgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.bz2=01;31:*.bz=01;31:*.tbz2=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.aac=00;36:*.au=00;36:*.flac=00;36:*.mid=00;36:*.midi=00
;36:*.mka=00;36:*.mp3=00;36:*.mpc=00;36:*.ogg=00;36:*.ra=00;36:*.wav=00;36:
PATH=/bin:/usr/bin:/sbin:/usr/sbin
MAIL=/var/mail/root
PWD=/opt/tomcat6/temp
JAVA_HOME=/usr/lib/jvm/java-6-sun
LANG=en_US.UTF-8
HOME=/root
SHLVL=2
LS_OPTIONS=--color=auto
LOGNAME=root
SSH_CONNECTION=84.158.8.209 1689 212.85.38.202 22
EFSDIR=/mnt/NAS/MIRA/EFS
LC_CTYPE=de_DE.iso885915@euro
_=/usr/bin/jsvc
OLDPWD=/root
(I picked the first of the above processes)
Thus, it does not seem that there is either a $LD_LIBRARY_PATH set, nor an explicit
"-Djava.library.path" on the tomcat (or jsvc) command-line.
(Or I am missing something).
So then, to repeat the question, where might this Tomcat Native library be, which Tomcat
finds and is complaining about ?
Here follows a list of files from the tomcat6 installation dir. Apart from
tomcat-native.tar.gz, I don't see anything there which looks like a tc-native library..
v2:/opt/tomcat6# ls -l
total 63
drwxrwxr-x 2 root root 1024 2011-12-09 16:33 bin
drwxr-xr-x 4 tomcat55 adm 1024 2011-12-12 21:19 conf
drwxr-xr-x 2 root root 1024 2011-12-09 12:02 lib
-rw-r--r-- 1 root root 37951 2011-11-28 11:22 LICENSE
drwxr-xr-x 2 tomcat55 adm 1024 2011-12-12 19:17 logs
-rw-r--r-- 1 root root 558 2011-11-28 11:22 NOTICE
-rw-r--r-- 1 root root 8680 2011-11-28 11:20 RELEASE-NOTES
-rw-r--r-- 1 root root 6670 2011-11-28 11:22 RUNNING.txt
drwxr-xr-x 2 tomcat55 root 1024 2011-12-09 16:10 temp
lrwxrwxrwx 1 root root 26 2011-12-09 15:01 webapps -> /var/lib/tomcat5.5/webapps
drwxr-xr-x 7 root root 1024 2011-11-28 11:20 webapps.orig
drwxr-xr-x 3 tomcat55 adm 1024 2011-12-09 17:08 work
v2:/opt/tomcat6# ls -l bin
total 596
-rw-r--r-- 1 star star 22705 2011-11-28 11:20 bootstrap.jar
-rw-r--r-- 1 star star 11830 2011-11-28 11:20 catalina.bat
-rwxr-xr-x 1 star star 17708 2011-11-28 11:20 catalina.sh
-rw-r--r-- 1 star star 2374 2011-11-28 11:20 catalina-tasks.xml
-rw-r--r-- 1 star star 24172 2011-11-28 11:20 commons-daemon.jar
-rw-r--r-- 1 star star 199623 2011-11-28 11:20 commons-daemon-native.tar.gz
-rw-r--r-- 1 star star 1342 2011-11-28 11:20 cpappend.bat
-rw-r--r-- 1 star star 2108 2011-11-28 11:20 digest.bat
-rwxr-xr-x 1 star star 1689 2011-11-28 11:20 digest.sh
-rw-r--r-- 1 star star 3150 2011-11-28 11:20 setclasspath.bat
-rwxr-xr-x 1 star star 4114 2011-11-28 11:20 setclasspath.sh
-rw-r--r-- 1 star star 2108 2011-11-28 11:20 shutdown.bat
-rwxr-xr-x 1 star star 1628 2011-11-28 11:20 shutdown.sh
-rw-r--r-- 1 star star 2109 2011-11-28 11:20 startup.bat
-rwxr-xr-x 1 star star 2023 2011-11-28 11:20 startup.sh
-rw-r--r-- 1 star star 32277 2011-11-28 11:20 tomcat-juli.jar
-rw-r--r-- 1 star star 249259 2011-11-28 11:20 tomcat-native.tar.gz
-rw-r--r-- 1 star star 3479 2011-11-28 11:20 tool-wrapper.bat
-rwxr-xr-x 1 star star 3472 2011-11-28 11:20 tool-wrapper.sh
-rw-r--r-- 1 star star 2113 2011-11-28 11:20 version.bat
-rwxr-xr-x 1 star star 1632 2011-11-28 11:20 version.sh
v2:/opt/tomcat6# find . -name tomcat-native*
./bin/tomcat-native.tar.gz
v2:/opt/tomcat6# find . -name tc*
v2:/opt/tomcat6#
> p
>
>
>>
>> Dec 12, 2011 12:37:14 PM org.apache.coyote.http11.Http11Protocol destroy
>> INFO: Stopping Coyote HTTP/1.1 on http-8180
>> 12.12.2011 12:37:24 org.apache.catalina.core.AprLifecycleListener init
>> SCHWERWIEGEND: An incompatible version 1.1.12 of the APR based Apache Tomcat Native library is installed, while Tomcat requires version 1.1.17
>> 12.12.2011 12:37:24 org.apache.coyote.http11.Http11Protocol init
>> INFO: Initializing Coyote HTTP/1.1 on http-8180
>> 12.12.2011 12:37:24 org.apache.catalina.startup.Catalina load
>> INFO: Initialization processed in 2079 ms
>> 12.12.2011 12:37:26 org.apache.catalina.core.StandardService start
>> INFO: Starting service Catalina
>> 12.12.2011 12:37:26 org.apache.catalina.core.StandardEngine start
>> INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
>> 12.12.2011 12:37:26 org.apache.catalina.startup.HostConfig deployDirectory
>> INFO: Deploying web application directory test
>> 12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig deployDirectory
>> INFO: Deploying web application directory dumpuser
>> 12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig deployDirectory
>> INFO: Deploying web application directory starweb
>> 12.12.2011 12:37:27 org.apache.coyote.http11.Http11Protocol start
>> INFO: Starting Coyote HTTP/1.1 on http-8180
>> 12.12.2011 12:37:27 org.apache.jk.common.ChannelSocket init
>> INFO: JK: ajp13 listening on /0.0.0.0:8009
>> 12.12.2011 12:37:27 org.apache.jk.server.JkMain start
>> INFO: Jk running ID=0 time=0/55 config=null
>> 12.12.2011 12:37:27 org.apache.catalina.startup.Catalina start
>> INFO: Server startup in 2993 ms
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: users-help@tomcat.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org
Re: path used for tc-natuve
Posted by Pid * <pi...@pidster.com>.
On 12 Dec 2011, at 16:37, "André Warnier" <aw...@ice-sa.com> wrote:
> Hi
>
> On a Debian Linux system, was running a Debian-pre-packaged Tomcat 5.5.
> We stopped this Tomcat 5.5, but did not remove the corresponding package(s).
> Then we installed an "official" Tomcat 6, downloaded from the Tomcat website, in /opt/tomcat6 as "CATALINA_HOME".
> We then made a copy of the /etc/init.d startup script which used to start Tomcat 5.5, and modified it to start this new Tomcat6 instead.
>
> Now when stopping and starting this Tomcat6, we are getting the message below (about APR) in the Tomcat6 logfile.
>
> My question is : where could Tomcat6 find this APR tc-native of the wrong version ?
> As far as I can tell, there is no unpacked tc-native anything in the Tomcat6 directories.
$LD_LIBRARY_PATH
Or check the -Djava.library.path set by the script.
p
>
>
> Dec 12, 2011 12:37:14 PM org.apache.coyote.http11.Http11Protocol destroy
> INFO: Stopping Coyote HTTP/1.1 on http-8180
> 12.12.2011 12:37:24 org.apache.catalina.core.AprLifecycleListener init
> SCHWERWIEGEND: An incompatible version 1.1.12 of the APR based Apache Tomcat Native library is installed, while Tomcat requires version 1.1.17
> 12.12.2011 12:37:24 org.apache.coyote.http11.Http11Protocol init
> INFO: Initializing Coyote HTTP/1.1 on http-8180
> 12.12.2011 12:37:24 org.apache.catalina.startup.Catalina load
> INFO: Initialization processed in 2079 ms
> 12.12.2011 12:37:26 org.apache.catalina.core.StandardService start
> INFO: Starting service Catalina
> 12.12.2011 12:37:26 org.apache.catalina.core.StandardEngine start
> INFO: Starting Servlet Engine: Apache Tomcat/6.0.35
> 12.12.2011 12:37:26 org.apache.catalina.startup.HostConfig deployDirectory
> INFO: Deploying web application directory test
> 12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig deployDirectory
> INFO: Deploying web application directory dumpuser
> 12.12.2011 12:37:27 org.apache.catalina.startup.HostConfig deployDirectory
> INFO: Deploying web application directory starweb
> 12.12.2011 12:37:27 org.apache.coyote.http11.Http11Protocol start
> INFO: Starting Coyote HTTP/1.1 on http-8180
> 12.12.2011 12:37:27 org.apache.jk.common.ChannelSocket init
> INFO: JK: ajp13 listening on /0.0.0.0:8009
> 12.12.2011 12:37:27 org.apache.jk.server.JkMain start
> INFO: Jk running ID=0 time=0/55 config=null
> 12.12.2011 12:37:27 org.apache.catalina.startup.Catalina start
> INFO: Server startup in 2993 ms
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: users-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org