You are viewing a plain text version of this content. The canonical link for it is here.
Posted to modperl@perl.apache.org by "Tiller, Michiel" <Mi...@bmc.com> on 2002/08/01 10:04:33 UTC

RE: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server f ails

Hmm.. I have only this week compiled the exact same versions of Apache and
mod_perl on Solaris 2.6, without any problems. I'd suggest to get the latest
gcc from:
ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/gcc-3.1-sol26-sparc-local.g
z

And it won't hurt to renew zlib,ncurses and gdbm either while you're at it:
ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/zlib-1.1.4-sol26-sparc-loca
l.gz
ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/ncurses-5.2-sol26-sparc-loc
al.gz
ftp://ftp.sunfreeware.com/pub/freeware/sparc/2.6/gdbm-1.8.0-sol26-sparc-loca
l.gz

Hope it helps.

Cheers,
Michiel


-----Original Message-----
From: John E. Mendenhall [mailto:jem@electriciti.com]
Sent: Wednesday, July 31, 2002 23:26
To: modperl@perl.apache.org
Subject: re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server
fails


I have compiled mod_perl 1.27 with apache 1.3.26 under perl 5.6.1, solaris
2.6.  When I run the make test, it fails with the following in the
error_log:

  [notice] Destruction->DESTROY called for $global_object
  Prototype mismatch: sub Socket::INADDR_ANY vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 329.
  Prototype mismatch: sub Socket::INADDR_BROADCAST vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 330.
  Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 331.
  Prototype mismatch: sub Socket::INADDR_LOOPBACK vs () at
/usr/local/lib/perl5/5.6.1/sun4-solaris/Socket.pm line 332.
  [Wed Jul 31 14:12:36 2002] [warn] [notice] child_init for process 10483,
report any problems to [no address given]

This might all be fine and good, but when the test tries to retrieve the
test.html document, the server immediately stops, with no other messages
anywhere.  If I start the httpd daemon separately from running the tests
(make start_httpd), it starts just fine.  If I attach a truss to the
single process (running under -X), then run the tests (make run_tests), I
get these errors:

------- truss log -------
# truss -p 10483
accept(16, 0xEFFFF8F0, 0xEFFFF8EC) (sleeping...)
accept(16, 0xEFFFF8F0, 0xEFFFF8EC)              = 3
fcntl(17, F_SETLKW64, 0x001994C8)               = 0
sigaction(SIGUSR1, 0xEFFFF730, 0xEFFFF830)      = 0
getsockname(3, 0xEFFFF900, 0xEFFFF8EC)          = 0
setsockopt(3, 6, 1, 0xEFFFF86C, 4)              = 0
brk(0x006E9000)                                 = 0
brk(0x006EB000)                                 = 0
brk(0x006EB000)                                 = 0
brk(0x006ED000)                                 = 0
alarm(300)                                      = 0
read(3, " G E T   / t e s t . h t".., 4096)     = 98
sigaction(SIGUSR1, 0xEFFFD640, 0xEFFFD740)      = 0
time()                                          = 1028149998
alarm(300)                                      = 300
alarm(0)                                        = 300
stat64("/usr/local/src/mod_perl/mod_perl-1.27/t/docs/test.html",
0x006E91E8) = 0
open64("/usr/local/src/mod_perl/mod_perl-1.27/t/.htaccess", O_RDONLY)
Err#2 ENOENT
open64("/usr/local/src/mod_perl/mod_perl-1.27/t/docs/.htaccess", O_RDONLY)
= 5
fstat64(5, 0xEFFFF5C0)                          = 0
fstat64(5, 0xEFFFD420)                          = 0
brk(0x006ED000)                                 = 0
brk(0x006EF000)                                 = 0
ioctl(5, TCGETA, 0xEFFFD3AC)                    Err#25 ENOTTY
read(5, "  ", 8192)                             = 1
read(5, 0x006EB104, 8192)                       = 0
read(5, 0x006EB104, 8192)                       = 0
llseek(5, 0, SEEK_CUR)                          = 1
close(5)                                        = 0
    Incurred fault #6, FLTBOUNDS  %pc = 0x0002D6F0
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000018
    Received signal #11, SIGSEGV [caught]
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000018
sigprocmask(SIG_SETMASK, 0xEF567D90, 0x00000000) = 0
sigaction(SIGSEGV, 0xEFFFF140, 0x00000000)      = 0
sigprocmask(SIG_SETMASK, 0xEF570A90, 0x00000000) = 0
setcontext(0xEFFFF300)
    Incurred fault #6, FLTBOUNDS  %pc = 0x0002D6F0
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000018
    Received signal #11, SIGSEGV [default]
      siginfo: SIGSEGV SEGV_MAPERR addr=0x00000018
        *** process killed ***
#

------- truss log end -------

I have used mod_perl up through versions 1.15, using perl 5.004_04,
earlier versions of Apache.  I am trying to upgrade to the latest stable
releases of everything and it just does not seem to be working.  I have
checked the list archives as well as google and anywhere else I could
think of and could not find why it is dying.  Any help is appreciated.

Thank you very much.

JohnM


## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator

Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Lupe Christoph <lu...@lupe-christoph.de>.
On Monday, 2002-08-12 at 12:41:54 +0800, Stas Bekman wrote:
> Lupe Christoph wrote:
> >On Thursday, 2002-08-08 at 15:48:48 -0700, John E. Mendenhall wrote:

> >>I have done all you have asked.  All output appears similar.  Three files,
> >>including Log.xs.  Nine entries in httpd for XS_Apache__Log, as follows:

> >>So, where to from here?  Any ideas?

> (Stas explains bootstrapping.)

Thank you for the explanation, Stas.

> What do you get from running:
> nm httpd | grep Apache__Log

> there should be boot_Apache__Log there.

On my working Solaris version, there is:
[3497]  |    464188|     732|FUNC |GLOB |0    |9      |boot_Apache__Log

Sorry for telling John a too restrictive string to grep.

>From Tim's explanation (which is now out of date on some technical
details, like perlmain.c), I gather that the following might be amiss
in John's installation:

xs_init() is used to introduce the statically linked XSes to mod_perl.
There must be a call to newXS for Apache::Log in it.

John, please check this:
grep boot_Apache__Log apache_1.3.26/src/modules/perl/perlxsi.c
EXTERN_C void boot_Apache__Log _((CV* cv));
        newXS("Apache::Log::bootstrap", boot_Apache__Log, file);

HTH,
Lupe Christoph
-- 
| lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
| I have challenged the entire ISO-9000 quality assurance team to a      |
| Bat-Leth contest on the holodeck. They will not concern us again.      |
| http://public.logica.com/~stepneys/joke/klingon.htm                    |

Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
Stas, Lupe, and modperl gurus,

Sorry for taking so long to respond to your messages.  I had some other
tasks to take care of.

> What do you get from running:
> nm httpd | grep Apache__Log
>
> there should be boot_Apache__Log there.

I get the following:

[2638]  |    286064|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_alert
[3893]  |    286280|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_crit
[3960]  |    287360|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_debug
[3382]  |    285848|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_emerg
[3619]  |    286496|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_error
[2981]  |    287144|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_info
[2566]  |    285508|     340|FUNC |GLOB |0    |8      |XS_Apache__Log_log
[3223]  |    286928|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_notice
[2866]  |    286712|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_warn
[4347]  |    287988|     772|FUNC |GLOB |0    |8      |boot_Apache__Log

And, Lupe wrote:

> John, please check this:
> grep boot_Apache__Log apache_1.3.26/src/modules/perl/perlxsi.c
> EXTERN_C void boot_Apache__Log _((CV* cv));
>         newXS("Apache::Log::bootstrap", boot_Apache__Log, file);

When I run the above grep, I get the following:

% grep boot_Apache__Log perlxsi.c
EXTERN_C void boot_Apache__Log (pTHXo_ CV* cv);
        newXS("Apache::Log::bootstrap", boot_Apache__Log, file);

So, it appears everything still looks okay.  What is the next step?  Some
sort of truss to determine where this is getting messed up?

JohnM

## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator



Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Stas Bekman <st...@stason.org>.
Lupe Christoph wrote:
> On Thursday, 2002-08-08 at 15:48:48 -0700, John E. Mendenhall wrote:
> 
>>On Thu, 8 Aug 2002, Lupe Christoph wrote:
> 
> 
>>>Since mod_perl seems to play tricks with bootstrap, I don't really
>>>know how this comes into play.
>>
> 
>>I have done all you have asked.  All output appears similar.  Three files,
>>including Log.xs.  Nine entries in httpd for XS_Apache__Log, as follows:
> 
> 
>>So, where to from here?  Any ideas?
> 
> 
> Well, this proves that Apache::Log *is* linked into the httpd binary.
> The questions is why bootstrap is called at all. I'm afraid, I have
> to hand this over to people who know the internal logic of mod_perl.
> bootstrap *should* not be called, I think.

bootstrap() is always needed, because that's the function that 
"installs" XSUBs into the corresponding Perl functions. The only 
difference between dynamically and statically linked libraries is the 
former is loading the object first and the latter have everything loaded 
already. Here is the explanation by Tim Bunce:
http://groups.google.com/groups?q=bootstrap+statically+linked+perl&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Cyy1rA.Lnp%40ig.co.uk&rnum=1

So as Tim says a statically linked library should already have its 
::bootstrap function (which is boot_Apache__Log in your case).

mod_perl::boot() (lib/mod_perl.pm) is the place where it decides whether 
to call DynaLoader's bootstrap() or the existing one:

sub boot {
     my($class, $version) = @_;
     no strict 'refs';
     *{$class.'::dl_load_flags'} = DynaLoader->can('dl_load_flags');
     if ($ENV{MOD_PERL}) {
         (defined &{$class.'::bootstrap'} ?
          \&{$class.'::bootstrap'} :
          \&DynaLoader::bootstrap)->
              ($class, $version);
     }
}

In your case defined &{$class.'::bootstrap'} should probably return a 
ref to Apache::Log::bootstrap() (boot_Apache__Log) and then call it. For 
some reason this doesn't happen and the DynaLoader's version is called, 
which of course fails to load the object.

What do you get from running:
nm httpd | grep Apache__Log

there should be boot_Apache__Log there.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Lupe Christoph <lu...@lupe-christoph.de>.
On Thursday, 2002-08-08 at 15:48:48 -0700, John E. Mendenhall wrote:
> On Thu, 8 Aug 2002, Lupe Christoph wrote:

> > Since mod_perl seems to play tricks with bootstrap, I don't really
> > know how this comes into play.

> I have done all you have asked.  All output appears similar.  Three files,
> including Log.xs.  Nine entries in httpd for XS_Apache__Log, as follows:

> So, where to from here?  Any ideas?

Well, this proves that Apache::Log *is* linked into the httpd binary.
The questions is why bootstrap is called at all. I'm afraid, I have
to hand this over to people who know the internal logic of mod_perl.
bootstrap *should* not be called, I think.

You could try to reduce your config until the error goes away.
Or start with a minimal startup.pl that only does a "use Apache::Log".
I fear the whatever that has a list of the modules linked into
httpd is scrambled by your production config.

Lupe Christoph
-- 
| lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
| I have challenged the entire ISO-9000 quality assurance team to a      |
| Bat-Leth contest on the holodeck. They will not concern us again.      |
| http://public.logica.com/~stepneys/joke/klingon.htm                    |

Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
Lupe,

On Thu, 8 Aug 2002, Lupe Christoph wrote:

> On Thursday, 2002-08-08 at 10:16:44 -0700, John E. Mendenhall wrote:
> > On Thu, 8 Aug 2002, Lupe Christoph wrote:
>
> > > Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
>
> > > Can't locate loadable object for module Apache::Log in @INC (@INC
> > > contains: /opt/cybercash/mck/perl-api
> > > /usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1
> > > /usr/local/lib/perl5/site_perl/5.6.1/ sun4-solaris
> > > /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl
> > > /usr/local/lib/perl5/si te_perl/sun4-solaris .
> > > /usr/local/apache-mod_perl/ /usr/local/apache-mod_perl/lib/perl) at
> > > /usr/local/li b/perl5/site_perl/5.6.1/sun4-solaris/mod_perl.pm line 14
>
> This looks OK.
>
> Since mod_perl seems to play tricks with bootstrap, I don't really
> know how this comes into play. The fate of Log.xs from
> mod_perl-1.26/src/modules/perl/Log.xs is:
> it is copied to apache_1.3.22/src/modules/perl/Log.xs, and
> apache_1.3.22/src/modules/perl/Log.c is generated from it.
> That in turn produces Log.o, which in the statically linked case
> I have, goes into libperl.a. And that is linked into httpd.
>
> Please check your apache_1.3.27/src/modules/perl for Log.*.
> If you have the three files, do "ar tv libperl.a" and look for Log.o.
> If this is still present, do "nm httpd | grep XS_Apache__Log".
> You should get a couple of lines like this:
> [3561]  |    503856|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_alert
> [6456]  |    504088|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_crit
> [5099]  |    505248|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_debug
> [6188]  |    503624|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_emerg
> [3426]  |    504320|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_error
> [3250]  |    505016|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_info
> [6242]  |    503272|     352|FUNC |GLOB |0    |9      |XS_Apache__Log_log
> [4790]  |    504784|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_notice
> [5051]  |    504552|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_warn
>
> Lupe Christoph

I have done all you have asked.  All output appears similar.  Three files,
including Log.xs.  Nine entries in httpd for XS_Apache__Log, as follows:

[2638]  |    286064|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_alert
[3893]  |    286280|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_crit
[3960]  |    287360|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_debug
[3382]  |    285848|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_emerg
[3619]  |    286496|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_error
[2981]  |    287144|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_info
[2566]  |    285508|     340|FUNC |GLOB |0    |8      |XS_Apache__Log_log
[3223]  |    286928|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_notice
[2866]  |    286712|     216|FUNC |GLOB |0    |8      |XS_Apache__Log_warn

So, where to from here?  Any ideas?

JohnM

## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator



Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Lupe Christoph <lu...@lupe-christoph.de>.
On Thursday, 2002-08-08 at 10:16:44 -0700, John E. Mendenhall wrote:
> On Thu, 8 Aug 2002, Lupe Christoph wrote:

> > There is no Log.so in my Solaris 8/Apache 1.3.22/mod_perl 1.26
> > installation. While I have src/modules/perl/Log.xs, this is not
> > used, but the Log.pm.

... and Log.pm ist a POD.

> > Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:

> > Can't locate loadable object for module Apache::Log in @INC (@INC
> > contains: /opt/cybercash/mck/perl-api
> > /usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1
> > /usr/local/lib/perl5/site_perl/5.6.1/ sun4-solaris
> > /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl
> > /usr/local/lib/perl5/si te_perl/sun4-solaris .
> > /usr/local/apache-mod_perl/ /usr/local/apache-mod_perl/lib/perl) at
> > /usr/local/li b/perl5/site_perl/5.6.1/sun4-solaris/mod_perl.pm line 14

This looks OK.

I have located the error message in ext/DynaLoader/DynaLoader_pm.PL
in perl (bleadperl, but that probably hasn't changed a long time).
It's in sub bootstrap.

Since mod_perl seems to play tricks with bootstrap, I don't really
know how this comes into play. The fate of Log.xs from
mod_perl-1.26/src/modules/perl/Log.xs is:
it is copied to apache_1.3.22/src/modules/perl/Log.xs, and
apache_1.3.22/src/modules/perl/Log.c is generated from it.
That in turn produces Log.o, which in the statically linked case
I have, goes into libperl.a. And that is linked into httpd.

Please check your apache_1.3.27/src/modules/perl for Log.*.
If you have the three files, do "ar tv libperl.a" and look for Log.o.
If this is still present, do "nm httpd | grep XS_Apache__Log".
You should get a couple of lines like this:
[3561]  |    503856|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_alert
[6456]  |    504088|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_crit
[5099]  |    505248|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_debug
[6188]  |    503624|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_emerg
[3426]  |    504320|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_error
[3250]  |    505016|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_info
[6242]  |    503272|     352|FUNC |GLOB |0    |9      |XS_Apache__Log_log
[4790]  |    504784|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_notice
[5051]  |    504552|     232|FUNC |GLOB |0    |9      |XS_Apache__Log_warn

If you have a dynamically linked mod_perl, check libexec/libperl.so.

HTH,
Lupe Christoph
-- 
| lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
| I have challenged the entire ISO-9000 quality assurance team to a      |
| Bat-Leth contest on the holodeck. They will not concern us again.      |
| http://public.logica.com/~stepneys/joke/klingon.htm                    |

Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Christian Couder <ch...@cetelem.fr>.
Lupe Christoph wrote:
> 
> Stas Bekman wrote:
> 
> > I don't think this is something new to 1.27. It's there for ages. May be
> >  you  don't have a support for shared libraries? Or do they called
> > differently on Solaris (which I doubt)? Anybody who uses mod_perl on
> > Solaris 2.6, can you please stand up and say a word or two here? Thanks.
> 
> There is no Log.so in my Solaris 8/Apache 1.3.22/mod_perl 1.26
> installation. While I have src/modules/perl/Log.xs, this is not
> used, but the Log.pm.

Hi,

There is no Log.so in my Solaris 2.6/Apache 1.3.20/mod_perl 1.26
installation.

I only have :

./site_perl/5.6.1/sun4-solaris/Apache/Log.pm

Regards, 
Christian Couder.

Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
Lupe (and modperl listeners),

On Thu, 8 Aug 2002, Lupe Christoph wrote:

> There is no Log.so in my Solaris 8/Apache 1.3.22/mod_perl 1.26
> installation. While I have src/modules/perl/Log.xs, this is not
> used, but the Log.pm.
>
> I can't find the mail Stas cited in the archive:
>
> John E. Mendenhall wrote:
> > I was able to get the test server working.  When I try to run it with
> > my
> > production configuration, it will not start, with the following error:
> >
> > -------  error message  -------
> > Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
> >
> > Can't locate loadable object for module Apache::Log in @INC (@INC
> > contains: /opt/cybercash/mck/perl-api
>
> Was that the complete @INC? Then it's no wonder it can't find it.
>
> HTH,
> Lupe Christoph

Sorry.  I probably cut it off.  I dislike these messages getting longer
and longer.  The complete error message was:

> -------  error message  -------
> Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
>
> Can't locate loadable object for module Apache::Log in @INC (@INC
> contains: /opt/cybercash/mck/perl-api
> /usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1
> /usr/local/lib/perl5/site_perl/5.6.1/ sun4-solaris
> /usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl
> /usr/local/lib/perl5/si te_perl/sun4-solaris .
> /usr/local/apache-mod_perl/ /usr/local/apache-mod_perl/lib/perl) at
> /usr/local/li b/perl5/site_perl/5.6.1/sun4-solaris/mod_perl.pm line 14
>
> Compilation failed in require at
> /usr/local/lib/perl5/site_perl/TKB_0_02/TrackSession.pm line 94.
> BEGIN failed--compilation aborted at
> /usr/local/lib/perl5/site_perl/TKB_0_02/TrackSession.pm line 94.
>
> Compilation failed in require at
> /usr/local/apache-mod_perl/scripts/startup.tkb.pl line 34.
> BEGIN failed--compilation aborted at
> /usr/local/apache-mod_perl/scripts/startup.tkb.pl line 34.
>
> Compilation failed in require at (eval 165) line 1.
> -------  end of message  -------

Hope this helps.  Please let me know if there is anything else I can try
to get this operational.  Thanks.

JohnM


## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator




Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Lupe Christoph <lu...@lupe-christoph.de>.
On Thursday, 2002-08-08 at 10:10:35 +0800, Stas Bekman wrote:
> John E. Mendenhall wrote:
> 
> >Checked mod_perl source directory.  No such Log.so file.  Reconfigured,
> >recompiled.  Checked again.  No such Log.so file.

> >I have a working modperl version 1.25, compiled under perl v 5.004_04.  I
> >am running this under Solaris 2.6.  The working version does not have a
> >loadable object Log.so anywhere.  So, why would this version require one.
> >I do not see it anywhere, not even in the new version 1.27 of modperl,
> >compiled using perl 5.6.1.

> >Is there something else I can check?  I really would like to get this new
> >version running with Apache 1.3.26.

> I don't think this is something new to 1.27. It's there for ages. May be 
>  you  don't have a support for shared libraries? Or do they called 
> differently on Solaris (which I doubt)? Anybody who uses mod_perl on 
> Solaris 2.6, can you please stand up and say a word or two here? Thanks.

There is no Log.so in my Solaris 8/Apache 1.3.22/mod_perl 1.26
installation. While I have src/modules/perl/Log.xs, this is not
used, but the Log.pm.

I can't find the mail Stas cited in the archive:

John E. Mendenhall wrote:
> I was able to get the test server working.  When I try to run it with
> my
> production configuration, it will not start, with the following error:
> 
> -------  error message  -------
> Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
> 
> Can't locate loadable object for module Apache::Log in @INC (@INC
> contains: /opt/cybercash/mck/perl-api

Was that the complete @INC? Then it's no wonder it can't find it.

HTH,
Lupe Christoph
-- 
| lupe@lupe-christoph.de       |           http://www.lupe-christoph.de/ |
| I have challenged the entire ISO-9000 quality assurance team to a      |
| Bat-Leth contest on the holodeck. They will not concern us again.      |
| http://public.logica.com/~stepneys/joke/klingon.htm                    |

Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Stas Bekman <st...@stason.org>.
John E. Mendenhall wrote:

> Checked mod_perl source directory.  No such Log.so file.  Reconfigured,
> recompiled.  Checked again.  No such Log.so file.
> 
> I have a working modperl version 1.25, compiled under perl v 5.004_04.  I
> am running this under Solaris 2.6.  The working version does not have a
> loadable object Log.so anywhere.  So, why would this version require one.
> I do not see it anywhere, not even in the new version 1.27 of modperl,
> compiled using perl 5.6.1.
> 
> Is there something else I can check?  I really would like to get this new
> version running with Apache 1.3.26.

I don't think this is something new to 1.27. It's there for ages. May be 
  you  don't have a support for shared libraries? Or do they called 
differently on Solaris (which I doubt)? Anybody who uses mod_perl on 
Solaris 2.6, can you please stand up and say a word or two here? Thanks.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
Stas (and modperl list),

On Wed, 7 Aug 2002, Stas Bekman wrote:

> John E. Mendenhall wrote:
> >>
> >>It looks for the loadable *object* (.so) not perl module (.pm). On my
> >>system these are:
> >>
> >>./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.bs
> >>./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.so
> >>./site_perl/5.6.1/i386-linux/Apache/Log.pm
> >>
> >>check that you  have the .so file:
> >>
> >>find /usr/local/lib/perl5 | grep Log.so
> >
> > No such file, anywhere, even in the previous releases currently deployed
> > in production (perl 5.004_04, mod_perl 1.25).  So, apparently, the Solaris
> > installation does not install a loadable object.  Why would it be looking
> > for one if one has never been installed?
>
> Because you probably have a borked mod_perl installation, go to the
> directory you built mod_perl in and do:
>
> % find . |grep Log.so
>
> you should get the Log.so file.
>
> Reinstall mod_perl from scratch and you will be all set.

Checked mod_perl source directory.  No such Log.so file.  Reconfigured,
recompiled.  Checked again.  No such Log.so file.

I have a working modperl version 1.25, compiled under perl v 5.004_04.  I
am running this under Solaris 2.6.  The working version does not have a
loadable object Log.so anywhere.  So, why would this version require one.
I do not see it anywhere, not even in the new version 1.27 of modperl,
compiled using perl 5.6.1.

Is there something else I can check?  I really would like to get this new
version running with Apache 1.3.26.

JohnM

## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator




Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Stas Bekman <st...@stason.org>.
John E. Mendenhall wrote:
> Stas,
> 
> 
>>>-------  error message  -------
>>>Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
>>>
>>>Can't locate loadable object for module Apache::Log in @INC (@INC
>>>contains: /opt/cybercash/mck/perl-api
>>>
>>>The Apache::Log module does exist, in two locations:
>>>
>>>-r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/Apache/Log.pm
>>>-r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/5.6.1/sun4-solaris/Apache/Log.pm
>>>
>>>I have already checked all parent directories to ensure the permissions
>>>are correct.
>>
>>It looks for the loadable *object* (.so) not perl module (.pm). On my
>>system these are:
>>
>>./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.bs
>>./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.so
>>./site_perl/5.6.1/i386-linux/Apache/Log.pm
>>
>>check that you  have the .so file:
>>
>>find /usr/local/lib/perl5 | grep Log.so
> 
> 
> No such file, anywhere, even in the previous releases currently deployed
> in production (perl 5.004_04, mod_perl 1.25).  So, apparently, the Solaris
> installation does not install a loadable object.  Why would it be looking
> for one if one has never been installed?

Because you probably have a borked mod_perl installation, go to the 
directory you built mod_perl in and do:

% find . |grep Log.so

you should get the Log.so file.

Reinstall mod_perl from scratch and you will be all set.

__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
Stas,

> > -------  error message  -------
> > Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
> >
> > Can't locate loadable object for module Apache::Log in @INC (@INC
> > contains: /opt/cybercash/mck/perl-api
> >
> > The Apache::Log module does exist, in two locations:
> >
> > -r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/Apache/Log.pm
> > -r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/5.6.1/sun4-solaris/Apache/Log.pm
> >
> > I have already checked all parent directories to ensure the permissions
> > are correct.
>
> It looks for the loadable *object* (.so) not perl module (.pm). On my
> system these are:
>
> ./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.bs
> ./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.so
> ./site_perl/5.6.1/i386-linux/Apache/Log.pm
>
> check that you  have the .so file:
>
> find /usr/local/lib/perl5 | grep Log.so

No such file, anywhere, even in the previous releases currently deployed
in production (perl 5.004_04, mod_perl 1.25).  So, apparently, the Solaris
installation does not install a loadable object.  Why would it be looking
for one if one has never been installed?

Anything else to check?

Thanks again for following through this with me.

JohnM

## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Stas Bekman <st...@stason.org>.
John E. Mendenhall wrote:
> I was able to get the test server working.  When I try to run it with my
> production configuration, it will not start, with the following error:
> 
> -------  error message  -------
> Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:
> 
> Can't locate loadable object for module Apache::Log in @INC (@INC
> contains: /opt/cybercash/mck/perl-api


[...]


> The trace is showing our PerlRequire file (startup.tkb.pl), which uses
> the TrackSession.pm module, which uses the Apache::Log module, which it
> cannot find.
> 
> The Apache::Log module does exist, in two locations:
> 
> -r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/Apache/Log.pm
> -r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/5.6.1/sun4-solaris/Apache/Log.pm
> 
> I have already checked all parent directories to ensure the permissions
> are correct.

It looks for the loadable *object* (.so) not perl module (.pm). On my 
system these are:

./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.bs
./site_perl/5.6.1/i386-linux/auto/Apache/Log/Log.so
./site_perl/5.6.1/i386-linux/Apache/Log.pm

check that you  have the .so file:

find /usr/local/lib/perl5 | grep Log.so



__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Marc Slagle <ma...@fulkertconsulting.com>.
> The old version is one we put on the server (Solaris 2.6).  We use
> perl5.6.1 as the command (located in /usr/local/bin) to configure the
> modperl module.  There are still production systems requiring perl5.004_04
> (default perl at /usr/bin/perl and /usr/local/bin/perl).
>
> When we try to bring up the server, we modify /usr/bin/perl and
> /usr/local/bin/perl to point to perl5.6.1 just to test it.  This is when
> we get the errors previously sent.

Have you started up the production server with truss?  That might show
something interesting...

Marc Slagle


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
Marc (and modperl gurus),


On Thu, 8 Aug 2002, Marc Slagle wrote:

> > We originally had perl version 5.004_04 on the system.  We have upgrade to
> > version 5.6.1.  Thus the two installations.
> >
> > Please let me know what I can try to get this working.  Or, if there is
> > some resource that can help me diagnose the problem, I would truly
> > appreciate it.  Thank you.
>
> Assuming that the old version of perl was the one that came with the Solaris
> install, you should have a directory called /usr/perl5.  I would check to
> see if there was anything new in that directory tree, just to make sure that
> the old version of perl isn't being seen during the compile.  I'd also go to
> the directory where you are building mod_perl and do a perl -V there to make
> sure it isnt using the old one.

There is no directory /usr/perl5.  We did not install Solaris 2.6 with a
perl binary.

> We had a problem like this where it seemed that a module that was installed
> wasn't being seen (Solaris 8).  The older version of perl on the system was
> still available as /usr/bin/perl, while the newer version we compiled
> ourselves was in /usr/local/bin/perl.  During the comple the old version
> came first in the path.
>
> We changed the path to pint to the new version of perl first
> (/usr/local/bin), re-compiled mod_perl, re-compiled apache, and that fixed
> it.
>
> Marc Slagle

The old version is one we put on the server (Solaris 2.6).  We use
perl5.6.1 as the command (located in /usr/local/bin) to configure the
modperl module.  There are still production systems requiring perl5.004_04
(default perl at /usr/bin/perl and /usr/local/bin/perl).

When we try to bring up the server, we modify /usr/bin/perl and
/usr/local/bin/perl to point to perl5.6.1 just to test it.  This is when
we get the errors previously sent.

Any other ideas?

JohnM

## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator


Re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by Marc Slagle <ma...@fulkertconsulting.com>.
> We originally had perl version 5.004_04 on the system.  We have upgrade to
> version 5.6.1.  Thus the two installations.
>
> Please let me know what I can try to get this working.  Or, if there is
> some resource that can help me diagnose the problem, I would truly
> appreciate it.  Thank you.

Assuming that the old version of perl was the one that came with the Solaris
install, you should have a directory called /usr/perl5.  I would check to
see if there was anything new in that directory tree, just to make sure that
the old version of perl isn't being seen during the compile.  I'd also go to
the directory where you are building mod_perl and do a perl -V there to make
sure it isnt using the old one.

We had a problem like this where it seemed that a module that was installed
wasn't being seen (Solaris 8).  The older version of perl on the system was
still available as /usr/bin/perl, while the newer version we compiled
ourselves was in /usr/local/bin/perl.  During the comple the old version
came first in the path.

We changed the path to pint to the new version of perl first
(/usr/local/bin), re-compiled mod_perl, re-compiled apache, and that fixed
it.

Hope this helps.

Marc Slagle


re: solaris 2.6, mod_perl 1.27, apache 1.3.26, resulting server fails

Posted by "John E. Mendenhall" <je...@electriciti.com>.
I was able to get the test server working.  When I try to run it with my
production configuration, it will not start, with the following error:

-------  error message  -------
Syntax error on line 1341 of /usr/local/apache/conf/httpd.conf:

Can't locate loadable object for module Apache::Log in @INC (@INC
contains: /opt/cybercash/mck/perl-api
/usr/local/lib/perl5/5.6.1/sun4-solaris /usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/
sun4-solaris /usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl /usr/local/lib/perl5/si
te_perl/sun4-solaris . /usr/local/apache-mod_perl/
/usr/local/apache-mod_perl/lib/perl) at /usr/local/li
b/perl5/site_perl/5.6.1/sun4-solaris/mod_perl.pm line 14

Compilation failed in require at
/usr/local/lib/perl5/site_perl/TKB_0_02/TrackSession.pm line 94.
BEGIN failed--compilation aborted at
/usr/local/lib/perl5/site_perl/TKB_0_02/TrackSession.pm line 94.

Compilation failed in require at
/usr/local/apache-mod_perl/scripts/startup.tkb.pl line 34.
BEGIN failed--compilation aborted at
/usr/local/apache-mod_perl/scripts/startup.tkb.pl line 34.

Compilation failed in require at (eval 165) line 1.
-------  end of message  -------

The trace is showing our PerlRequire file (startup.tkb.pl), which uses
the TrackSession.pm module, which uses the Apache::Log module, which it
cannot find.

The Apache::Log module does exist, in two locations:

-r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/Apache/Log.pm
-r--r--r--  1 root root 651 Jan 31 1999 ./site_perl/5.6.1/sun4-solaris/Apache/Log.pm

I have already checked all parent directories to ensure the permissions
are correct.

We originally had perl version 5.004_04 on the system.  We have upgrade to
version 5.6.1.  Thus the two installations.

Please let me know what I can try to get this working.  Or, if there is
some resource that can help me diagnose the problem, I would truly
appreciate it.  Thank you.

JohnM

## John Mendenhall
## jem@electriciti.com
## Senior Network/Systems Administrator