troubleshooting

Hi,

Server: Apache/2.2.3 (Debian) mod_perl/2.0.2 Perl/v5.8.8

I got to work this morning at my httpd daemon was down. I was getting
a seg fault whenever I tried to restart the daemon. I found an
upgraded package for my OS. It looks like I had a apache2 with MP1
setup. The new installation is MP2:

My startup file has:

use Apache2::RequestRec ();
use Apache::Const -compile qw(ok);
use Template;
use Date::Calc;

Now httpd won't start because:

Subroutine load redefined at /usr/lib/perl5/Apache2/XSLoader.pm line
28.\nCompilation failed in require at
/usr/lib/perl5/Apache2/RequestRec.pm line 24.

I have a feeling that my installation is screwed but I'm not sure how
to begin fixing it.

Can anyone offer any advice? Thanx.
Dp.

Re: troubleshooting

On Mon, Mar 17, 2008 at 7:06 AM, Beginner wrote:
> I found an
> upgraded package for my OS.

Do you mean that the OS auto-upgraded something, or that you upgraded
something manually? What exactly was upgraded?

> My startup file has:
>
> use Apache2::RequestRec ();
> use Apache::Const -compile qw(ok);
> use Template;
> use Date::Calc;

That looks fine.

> Subroutine load redefined at /usr/lib/perl5/Apache2/XSLoader.pm line
> 28.\nCompilation failed in require at
> /usr/lib/perl5/Apache2/RequestRec.pm line 24.

That sort of thing usually means that your mod_perl was not compiled
with the current perl and needs to be recompiled.

- Perrin

Re: troubleshooting

On 17 Mar 2008 at 7:43, Perrin Harkins wrote:

> On Mon, Mar 17, 2008 at 7:06 AM, Beginner wrote:
> > I found an
> > upgraded package for my OS.
>
> Do you mean that the OS auto-upgraded something, or that you upgraded
> something manually? What exactly was upgraded?

It looks like logrotate shutdown httpd and http failed to start after
that. I did an update to spamassassin, clamav and courier last week
but that went fine and there were no issues.

> > My startup file has:
> >
> > use Apache2::RequestRec ();
> > use Apache::Const -compile qw(ok);
> > use Template;
> > use Date::Calc;

I think the Apache::Const should be Apache2::Const but it hasn't
stopped the error.

> That looks fine.
>
> > Subroutine load redefined at /usr/lib/perl5/Apache2/XSLoader.pm line
> > 28.\nCompilation failed in require at
> > /usr/lib/perl5/Apache2/RequestRec.pm line 24.
>
> That sort of thing usually means that your mod_perl was not compiled
> with the current perl and needs to be recompiled.

mod_perl seems to come as part of the package on my version of
Debian. If i attempt to install I get "libapache2-mod-perl2 is
already the newest version".

I am loath to go down the route of install modperl from source as it
kinda breaks the idea behind having a package manager.

I'm am going to see if I can find a solution that maintains the
integrity of my package manager for now. If I haven't found a
solution by the end of the day I will have to go down the source
route.

Thanx,
Dp.

Re: troubleshooting

Dp,

Make sure you are using etch or later:
dpkg -l libapache2-mod-perl2

should list the installed version as 2.0.2-2.4


The sarge libapache2-mod-perl2 versions (1.99.xxx) were not sane.

Regards
Jeff

-------- Original Message --------
Subject: Re:troubleshooting
From: Beginner
To: modperl@perl.apache.org
Date: 17 March 2008 12:30:17

Re: troubleshooting

On Mon, 2008-03-17 at 12:30 +0000, Beginner wrote:
> On 17 Mar 2008 at 7:43, Perrin Harkins wrote:
>
> > On Mon, Mar 17, 2008 at 7:06 AM, Beginner wrote:
> > > I found an
> > > upgraded package for my OS.
> >
> > Do you mean that the OS auto-upgraded something, or that you upgraded
> > something manually? What exactly was upgraded?
>
> It looks like logrotate shutdown httpd and http failed to start after
> that. I did an update to spamassassin, clamav and courier last week
> but that went fine and there were no issues.
>
> > > My startup file has:
> > >
> > > use Apache2::RequestRec ();
> > > use Apache::Const -compile qw(ok);
> > > use Template;
> > > use Date::Calc;
>
> I think the Apache::Const should be Apache2::Const but it hasn't
> stopped the error.
>
> > That looks fine.
> >
> > > Subroutine load redefined at /usr/lib/perl5/Apache2/XSLoader.pm line
> > > 28.\nCompilation failed in require at
> > > /usr/lib/perl5/Apache2/RequestRec.pm line 24.
> >
> > That sort of thing usually means that your mod_perl was not compiled
> > with the current perl and needs to be recompiled.
>
> mod_perl seems to come as part of the package on my version of
> Debian. If i attempt to install I get "libapache2-mod-perl2 is
> already the newest version".

Try this:
dpkg -i --force /var/cache/archives/libapache2-mod-perl2-.deb

>
> I am loath to go down the route of install modperl from source as it
> kinda breaks the idea behind having a package manager.

Why must you go outside the package manager to install a custom-compiled
mod_perl? You can easily build debian packages on your own. Google is
full of howto's.

>
> I'm am going to see if I can find a solution that maintains the
> integrity of my package manager for now. If I haven't found a
> solution by the end of the day I will have to go down the source
> route.

I would highly recommend NOT going outside the package manager. Build
your own deb package, it's pretty straightforward.

>
> Thanx,
> Dp.

Re: troubleshooting

On Monday 17 March 2008 08:30:17 am Beginner wrote:

> > Do you mean that the OS auto-upgraded something, or that you upgraded
> > something manually? What exactly was upgraded?

> It looks like logrotate shutdown httpd and http failed to start after
> that.

For reference, that seems to be caused by the debian (and derivatives)
logrotate script to apache not actually waiting for apache to shutdown before
trying to restart it.

So it tells apache to shut down, rotates the logs and then tries to restart
apache - but as apache hasn't actually finished shutting down it refuses to
restart.

How log apache takes to shut down depends on what you're doing with it, so I
suspect this works with a simple apache config (as apache shuts down in time
to be restarted), but doesn't work well with a more complex mod_perl setup
where it takes longer to shut down.

The one debian based box I have to deal with ended up with a "sleep 30" in the
log rotate script, but it's not a production box so a 30 second outage at
midnight on a sunday isn't a problem. There are cleaner ways to handle this,
it just wasn't worth it in my particular case.

Re: troubleshooting

Hi.

First, you should probably pay more attention to what Perrin tells you,
rather than to what I tell you below. He is the real expert, I just dabble.
So you should probably first verify the version of Perl on your system,
and maybe try an update of that, before you look at what follows.

This being said, I also manage two Debian systems of slightly different
versions, and because of the different Debian package levels available I
have to maintain at the moment a different mod_perl startup script on
each. The point is that, at some precise level of mod_perl versions
(1.99xx, I don't remember exactly but you can find out on
http://perl.apache.org), the names of many modules changed, from
Apache:: to Apache2::.
(It is annoying, but the new naming is much cleaner, so it's better in
the long run).
Below I show my two startup scripts. Probably not all of that applies
to you, but it may be worth verifying.

mod_perl 2.x (more recent Debian version)

# Apache2 / mod_perl 2 startup script

use Bundle::Apache2 ();
use Apache2::compat ();
use lib "/usr/local/lib/apache2/perllib";
use ModPerl::Util ();
use Apache2::RequestRec ();
use Apache2::RequestIO ();
use Apache2::RequestUtil ();
use Apache2::Filter ();
use Apache2::ServerUtil ();
use Apache2::Connection ();
use Apache2::Log ();
use Apache2::Const -compile => qw(:common :log REDIRECT);
use APR::Const -compile => ':common';
use APR::Table ();
use ModPerl::Registry ();
use CGI ();
CGI->compile(':all');
1;


mod_perl 1.9x (older Debian version)

# Apache2 / mod_perl 2 startup script

use Apache2 ();
use Apache::compat ();
use lib "/usr/lib/apache2/perllib";
use ModPerl::Util ();
use Apache::RequestRec ();
use Apache::RequestIO ();
use Apache::RequestUtil ();
use Apache::Filter ();
use Apache::ServerUtil ();
use Apache::Connection ();
use Apache::Log ();
use Apache::Const -compile => qw(:common :log REDIRECT);
use APR::Const -compile => ':common';
use APR::Table ();
use ModPerl::Registry ();
use CGI ();
CGI->compile(':all');
1;

Note : I do not remember why in the first script I "use
Bundle::Apache2", and not in the second.

Hope this helps,
André

P.S.
And, by the way, if one of the experts here knows a better/cleaner way
than the above, please let me know.


Beginner wrote:
> On 17 Mar 2008 at 7:43, Perrin Harkins wrote:
>
>> On Mon, Mar 17, 2008 at 7:06 AM, Beginner wrote:
>>> I found an
>>> upgraded package for my OS.
>> Do you mean that the OS auto-upgraded something, or that you upgraded
>> something manually? What exactly was upgraded?
>
> It looks like logrotate shutdown httpd and http failed to start after
> that. I did an update to spamassassin, clamav and courier last week
> but that went fine and there were no issues.
>
>>> My startup file has:
>>>
>>> use Apache2::RequestRec ();
>>> use Apache::Const -compile qw(ok);
>>> use Template;
>>> use Date::Calc;
>
> I think the Apache::Const should be Apache2::Const but it hasn't
> stopped the error.
>
>> That looks fine.
>>
>>> Subroutine load redefined at /usr/lib/perl5/Apache2/XSLoader.pm line
>>> 28.\nCompilation failed in require at
>>> /usr/lib/perl5/Apache2/RequestRec.pm line 24.
>> That sort of thing usually means that your mod_perl was not compiled
>> with the current perl and needs to be recompiled.
>
> mod_perl seems to come as part of the package on my version of
> Debian. If i attempt to install I get "libapache2-mod-perl2 is
> already the newest version".
>
> I am loath to go down the route of install modperl from source as it
> kinda breaks the idea behind having a package manager.
>
> I'm am going to see if I can find a solution that maintains the
> integrity of my package manager for now. If I haven't found a
> solution by the end of the day I will have to go down the source
> route.
>
> Thanx,
> Dp.
>

Re: troubleshooting

On 17 Mar 2008 at 12:56, Jeff Armstrong wrote:

> Dp,
>
> Make sure you are using etch or later:
> dpkg -l libapache2-mod-perl2
>
> should list the installed version as 2.0.2-2.4
>
>
> The sarge libapache2-mod-perl2 versions (1.99.xxx) were not sane.


Apache/2.2.3 (Debian) mod_perl/2.0.2 Perl/v5.8.8

dpkg -l libapache2-mod-perl2 shows:

ii libapache2-mod-perl2 2.0.2-2.4

It doesn't mention etch but I think this is the correct version.

My archive for apt doesn't have the libapache2-mod-perl2.deb file any
longer. So I downloaded the version for my hardware (Alpha) and tried
again:

Unpacking replacement libapache2-mod-perl2 ...
Setting up libapache2-mod-perl2 (2.0.2-2.4) ...
apache2 -k start ; tail -f /var/log/apache2/error.log

Subroutine load redefined at /usr/lib/perl5/Apache2/XSLoader.pm line
28.\nCompilation failed in require at
/usr/lib/perl5/Apache2/RequestRec.pm

I am lost at this point. I think my install is correct in terms of
version numbers.

RequestRec reads:

use Apache2::XSLoader ();
our $VERSION = '2.000002';
Apache2::XSLoader::load __PACKAGE__;

XSLoader doesn't offer a version number.

I'd appreciate any ideas at this point. Thanx.
Dp.

Re: troubleshooting

Beginner wrote:
> dpkg -l libapache2-mod-perl2 shows:
>
> ii libapache2-mod-perl2 2.0.2-2.4
>
> It doesn't mention etch but I think this is the correct version.

FYI, here are the versions I get for Debian testing (I believe that's
etch at the moment?).

cww@iron.dev:~$ dpkg -l libapache2-mod-perl\* perl\* apache\* | egrep ^ii
ii apache2 2.2.6-2
Next generation, scalable, extendable web se
ii apache2-mpm-prefork 2.2.8-1
Traditional model for Apache HTTPD
ii apache2-utils 2.2.6-2
utility programs for webservers
ii apache2.2-common 2.2.8-1
Next generation, scalable, extendable web se
ii libapache2-mod-perl2 2.0.3-2
Integration of perl with the Apache2 web ser
ii libapache2-mod-perl2-doc 2.0.3-2
Integration of perl with the Apache2 web ser
ii perl 5.8.8-12
Larry Wall's Practical Extraction and Report
ii perl-base 5.8.8-12
The Pathologically Eclectic Rubbish Lister
ii perl-doc 5.8.8-12
Perl documentation
ii perl-mapscript 5.0.0-3
Perl MapServer library
ii perl-modules 5.8.8-12
Core Perl modules

These all work wonderfully together.

You probably don't need perl-mapscript, but at least have a look at the
rest of them.

Colin

Re: troubleshooting

Colin Wetherbee wrote:
> Beginner wrote:
>> dpkg -l libapache2-mod-perl2 shows:
>>
>> ii libapache2-mod-perl2 2.0.2-2.4
>>
>> It doesn't mention etch but I think this is the correct version.
>
> FYI, here are the versions I get for Debian testing (I believe that's
> etch at the moment?).
>
> cww@iron.dev:~$ dpkg -l libapache2-mod-perl\* perl\* apache\* | egrep ^ii

This, too:

cww@iron.dev:~$ dpkg -l \*apr\* | egrep ^ii
ii libapache2-mod-apreq2 2.08-5
generic Apache request library - Apache modu
ii libapr1 1.2.11-1
The Apache Portable Runtime Library
ii libapreq2 2.08-5
generic Apache request library
ii libaprutil1
1.2.12+dfsg-2 The Apache Portable Runtime Utility Library

Colin

Re: troubleshooting

Colin Wetherbee wrote:
> Beginner wrote:
>> dpkg -l libapache2-mod-perl2 shows:
>>
>> ii libapache2-mod-perl2 2.0.2-2.4
>>
>> It doesn't mention etch but I think this is the correct version.
>
> FYI, here are the versions I get for Debian testing (I believe that's
> etch at the moment?).

I'm making lots of noise here... my apologies. Debian stable is
currently etch, testing is lenny, and unstable is sid.

So, my package list was for lenny, not etch.

http://www.debian.org/releases/

That said, if you're not using this server for production or
mission-critical stuff, lenny might be a good direction to go. :)

Colin

Re: troubleshooting

On 17 Mar 2008 at 10:38, Colin Wetherbee wrote:

> Colin Wetherbee wrote:
> > Beginner wrote:
> >> dpkg -l libapache2-mod-perl2 shows:
> >>
> >> ii libapache2-mod-perl2 2.0.2-2.4
> >>
> >> It doesn't mention etch but I think this is the correct version.
> >
> > FYI, here are the versions I get for Debian testing (I believe that's
> > etch at the moment?).

I noticed that your using testing. As I am using a rather exotic
processor in Alpha, I am not tempted to stray off the stable path.

What I do want to do is reboot the system as there have been a number
of changes and I want to be sure there effects in place.

Thanx for the list though. I have compared it to what was on mine,
added the odd missing module but it hasn't resolved the error.

There are 2 XSLoader on under Apache2 and another under APR, the only
difference being

__END__ in the APR version.

I am currently trying to port the application onto a i586 machine, it
will take some reconfiguring to do get it working by tomorrow but at
least it can work on that machine.

Thanx,
Dp.