Hi; OK, I have apparently succeeded in my efforts to get mod_perl 2.0.1 onto Apache 2.0.54 with mod_ssl on HP-UX 11.11.
I think there are some (admittedly platform/environment-specific) notes that might benefit others by being added to some part of the documentation. I realize that this is somewhat lengthy, but it's taken me nearly two weeks to piece it all together, so if I can save anyone hours of headache, then... Here's the setup restrictions, which aren't a complete corner case I hope: - HP-UX 11.x - Perl which uses (either of) DBD::Oracle, DBD::Informix - Apache 2.0.44 or greater, running mod_ssl - some utilities sourced from TheWrittenWord (TWW) OK, a deep breath, and let's go! ############### --> Learning #1 - DBD::Oracle has special Perl build needs. ############### The DBD::Oracle installation states (in its README.hpux): It is important to build a non-threaded perl, but linked with -lcl and -lpthread. Since Oracle on HP uses libpthread, everything that dynamically loads it (such as DBD-Oracle) must have been built/linked with '-lpthread -lcl'. (When used with Apache, it and any associated modules these must also be built this way - otherwise all it does is core dump when loading DBD::Oracle). So, Perl was build this way a long time ago. This leads to: ############### --> Learning #2 - HP-UX and mod_perl 2.x have C++ issues resulting in the need to rebuild Apache with a custom stub. ############### When you start into mod_perl, 'make test' fails due to a shl_load error. (I've lost the exact error string). As it turns out, HP-UX's shl_load man page states in part "If the shared library contains thread local storage, you cannot load it with this routine." Of course, this is due to the DBD::Oracle requirement above, combined with the Apache newer than 2.0.44 coming up next... This error I traced (thank you Google!) to a helpful forum (among other locations), where I found in part: http://forums.datadirect.com/forums/thread.jspa?threadID=853&tstart=0 HP-UX: The dlopen() system call in HP-UX has problems when loading/unloading C++ modules. The problem can be resolved by using shl_load() instead of dlopen(). This is fixed in the Apache 2.0.44 release. To enable loading of C++ modules, the httpd binary has to be linked with the following libraries : HP-UX (11.0 / 11i): When using shl_load : "cpprt0_stub.s -lcl" When using dlopen : "cpprt0_stub.s -lcl -lCsup" HP-UX (11i version 1.5 and greater): When using dlopen/shl_load : "cpprt0_stub.s -lcl -lunwind" So, tracking down this stub file (it's only about 10 lines), I then included it in the (re-)build of Apache 2.0.54. Great! Oh, no, *now* make test fails with the "Can't locate TestFilter/in_str_consume.pm in @INC..." error already discussed in the mod_perl Troubleshooting guide. This we have hashed out here, and yes, it appears that on HP-UX, the 'maxfiles' kernel param is totally respected, instead of 'maxfile_lim'. So much for soft limits... OK, Stas says muck with ulimit. Here's the relevant snippet from my man page for HP-UX 'ksh': ulimit [-HSacdfst] [limit] Set or display a resource limit. -a List all of the current resource limits. -c List or set the number of 512-byte blocks in the size of core dumps. -d List or set the number of kilobytes in the size of the data area. -f List or set the number of 512-byte blocks in files written by child processes (files of any size can be read). -s List or set the number of kilobytes in the size of the stack area. -t List or set the number of seconds to be used by each process. As you can see, on older versions of ksh (11/16/88 or older) ulimit does not allow for setting numbers of files, only the writable size. If your ksh is 12/28/93 or newer, then ulimit does include the '-n' option and Learning #3 can be ignored. ############### --> Learning #3 - make test must be run under bash or a more modern version of ksh, where you can do 'ulimit -n 1024' (assuming that maxfile_lim will let you), *or* your kernel needs to actually set maxfiles to 1024 or more. ############### Next hurdle, httpd hangs on start (also from the Troubleshooting guide), tracked down to not enough randomness. *This* is because The Written Word installs all its tools under /opt/TWWfsw,/var/opt/TWWfsw, and so forth. So although my Apache conf file understands where to get the randomness pool (in this case /var/opt/TWWfsw/prngd/pool) mod_perl's configuration doesn't seem to be flexible about this, even though the openssl stuff is *also* from TWW. HOWEVER, OpenSSL (revision 0.9.7 or greater only) says in its docs "On systems without /dev/*random devices providing entropy from the kernel, the EGD entropy gathering daemon can be used to collect entropy. [...] OpenSSL automatically queries EGD when entropy is requested via RAND_bytes() or the status is checked via RAND_status() for the first time, if the socket is located at /var/run/egd-pool, /dev/egd-pool or /etc/egd-pool." So finally: ############### --> Learning #4 - gotta trick OpenSSL if you're using TWW ############### ln -s /dev/egd-pool /var/opt/TWWfsw/prngd/pool And lo and behold, mod_perl passes 'make test' and boy, I could use a beer :-) I hope some of this might be useful (when properly condensed) in the mod_perl troubleshooting guide somewhere, and possibly a finer-grained check of ulimit's actual capabilities (what `echo $SHELL` | grep -i Version) might enable a clear error message. Thanks for your patient reading if you got here. hugh Stas Bekman wrote: > Hugh Williams wrote: > > Stas Bekman wrote: > > > > > >what's your shell's file descriptors limit? run either: > > > > > >csh: limit > > >bash: ulimit > > > > I'm actually doing all work under ksh; here's all three results: > > > > $ ksh > > hughw on valhalla: /opt/build/mod_perl-2.0.1 > > $ ulimit > > unlimited > > > > $ csh > > valhalla mod_perl-2.0.1[1] % limit > > cputime unlimited > > filesize unlimited > > datasize 524288 kbytes > > stacksize 8192 kbytes > > coredumpsize 2097151 kbytes > > descriptors 60 files > ^^^ > This your problem. Your shells are configured to have too few file > descriptors. > > actually ulimit -n shows you just the descriptors limit in bash. I'm not > sure what's the syntax in ksh. > > so first run: > > ulimit -n 1024 > > or its equivalent in ksh and then run 'make test' again in that very shell. > > Ideally Apache-Test should be able to set this limit to the required one > at run time. ----- End of forwarded message from Stas Bekman ----- -- Hugh Williams "There are two things to aim for in life; [EMAIL PROTECTED] first, to get what you want; and after that, Agilent Technologies to enjoy it. Only the wisest of mankind Santa Rosa 2US-C achieve the second." 707.577.4941 - Logan Pearsall Smith, 1931