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
