Re: path used for tc-natuve
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: path used for tc-natuve
> From: Christopher Schultz [mailto:ch...@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
-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
Re: path used for tc-natuve
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
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
Re: path used for tc-natuve
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
Caldarale, Charles R wrote: From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: path used for tc-natuve
> From: André Warnier [mailto:a...@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
Gregor S. wrote: Hi Chuck! On Thu, Dec 15, 2011 at 5:36 PM, Caldarale, Charles R wrote: From: Gregor S. [mailto:rc4...@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.1 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 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,
Re: path used for tc-natuve
Hi Chuck! On Thu, Dec 15, 2011 at 5:36 PM, Caldarale, Charles R wrote: >> From: Gregor S. [mailto:rc4...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
-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 > 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: path used for tc-natuve
> From: Gregor S. [mailto:rc4...@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
...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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
Hi Chris, On Thu, Dec 15, 2011 at 4:34 PM, Christopher Schultz 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
Hi André, On Thu, Dec 15, 2011 at 3:45 PM, André Warnier 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
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 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:a...@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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
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:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
-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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chuck, On 12/12/11 8:27 PM, Caldarale, Charles R wrote: >> From: André Warnier [mailto:a...@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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: path used for tc-natuve
> From: André Warnier [mailto:a...@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
> From: André Warnier [mailto:a...@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 ? > 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
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 ? - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
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 root901 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-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: path used for tc-natuve
> 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
On 12/12/2011 22:25, André Warnier wrote: > Pid * wrote: >> On 12 Dec 2011, at 16:37, "André Warnier" 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 d
Re: path used for tc-natuve
On Mon, Dec 12, 2011 at 23:25, André Warnier 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 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
RE: path used for tc-natuve
> From: André Warnier [mailto:a...@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
Pid * wrote: On 12 Dec 2011, at 16:37, "André Warnier" 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
Re: path used for tc-natuve
On 12 Dec 2011, at 16:37, "André Warnier" 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-unsubscr...@tomcat.apache.org > For additional commands, e-mail: users-h...@tomcat.apache.org > - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
Re: path used for tc-natuve
On Mon, Dec 12, 2011 at 17:36, André Warnier 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 f...@one2team.com 40 avenue Raymond Poincaré 75116 Paris - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
