Can't locate RT.pm - in 3.8-testing since beta2


#1

Something changed in 3.8-TESTING which broke RT on my system. When I
perform the upgrade and restart Apache, Apache fails to start, with the
following error in my log file:

[error] Can’t locate RT.pm in @INC (@INC contains:
/usr/sbin/…/local/lib /usr/sbin/…/lib
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .
/etc/httpd) at /opt/rt3/bin/webmux.pl line 82.

I’ve narrowed down the problem to this 2008-05-15 change.

---------------------------------- aclocal.m4
index 9c6b641…95349dc 100755
@@ -30,7 +30,7 @@ AC_ARG_ENABLE(layout,
LAYOUT=$enableval)

if test “x$LAYOUT” = “x”; then

  • LAYOUT=“RT3”
  • LAYOUT="relative"
    fi
    RT_LAYOUT($srcdir/config.layout, $LAYOUT)
    AC_MSG_CHECKING(for chosen layout)

Here is how I typically do an upgrade:
aclocal && autoconf && ./configure --with-apachectl=/usr/sbin/apachectl
–with-web-handler=modperl2 && make testdeps

If I add --enable-layout=RT3 to my configure invocation, it seems to fix
the problem. Is this the right solution? Should I rather do something to
my Apache configuration so it can find the RT files? Or is it a bug?
Maybe something needs to be mentioned about layouts in the README and/or
UPGRADING files.
Jason


#2

Jason Long wrote:

Something changed in 3.8-TESTING which broke RT on my system.

If I add --enable-layout=RT3 to my configure invocation, it seems to fix
the problem. Is this the right solution? Should I rather do something to
my Apache configuration so it can find the RT files? Or is it a bug?

After closer examination, I think this is a bug. The problem is that
FindBin is using “/usr/sbin/httpd” as the program name, rather than
/opt/rt3/bin/webmux.pl. So webmux.pl goes looking for the RT library
files in /usr/lib instead of /opt/rt3/lib.

I suggest changing the default layout back to RT3. At least when using
mod_perl.
Jason


#3

Hi Jason

yeah, now ‘relative’ is the default layout, because we want RT be more
relocatable.

I just improved the way of resolving the relative lib path, which I
think can fix the problem you encountered.

check it out :slight_smile:

best wishes
sunnavyOn May 30, 2008, at 10:31 PM, Jason Long wrote:

Something changed in 3.8-TESTING which broke RT on my system. When I
perform the upgrade and restart Apache, Apache fails to start, with
the
following error in my log file:

[error] Can’t locate RT.pm in @INC (@INC contains:
/usr/sbin/…/local/lib /usr/sbin/…/lib
/usr/lib/perl5/site_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.8 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.8/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.8 /usr/lib/perl5/vendor_perl
/usr/lib/perl5/5.8.8/i386-linux-thread-multi /usr/lib/perl5/5.8.8 .
/etc/httpd) at /opt/rt3/bin/webmux.pl line 82.

I’ve narrowed down the problem to this 2008-05-15 change.

---------------------------------- aclocal.m4

index 9c6b641…95349dc 100755
@@ -30,7 +30,7 @@ AC_ARG_ENABLE(layout,
LAYOUT=$enableval)

if test “x$LAYOUT” = “x”; then

  • LAYOUT=“RT3”
  • LAYOUT="relative"
    fi
    RT_LAYOUT($srcdir/config.layout, $LAYOUT)
    AC_MSG_CHECKING(for chosen layout)

Here is how I typically do an upgrade:
aclocal && autoconf && ./configure --with-apachectl=/usr/sbin/
apachectl
–with-web-handler=modperl2 && make testdeps

If I add --enable-layout=RT3 to my configure invocation, it seems to
fix
the problem. Is this the right solution? Should I rather do
something to
my Apache configuration so it can find the RT files? Or is it a bug?
Maybe something needs to be mentioned about layouts in the README
and/or
UPGRADING files.
Jason


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel


#4

sunnavy wrote:

I just improved the way of resolving the relative lib path, which I
think can fix the problem you encountered.

check it out :slight_smile:

Thanks. Apache now starts successfully.

However, when I load an RT page in my browser, I get “internal server
error”, and this message in my Apache log file:

[client 10.42.34.240] Log file ‘var/log/rt.log’ couldn’t be written or
created.\n RT can’t run. at /opt/rt3/bin/…/lib/RT.pm line 300,
line 276.\n, referer: http://rttest.messiah.edu/Admin/CustomFields/

Jason


#5

When I have received this error, I just needed to touch var/log/rt.log

Jason Long wrote:

sunnavy wrote:

I just improved the way of resolving the relative lib path, which I
think can fix the problem you encountered.

check it out :slight_smile:

Thanks. Apache now starts successfully.

However, when I load an RT page in my browser, I get “internal server
error”, and this message in my Apache log file:

[client 10.42.34.240] Log file ‘var/log/rt.log’ couldn’t be written or
created.\n RT can’t run. at /opt/rt3/bin/…/lib/RT.pm line 300,
line 276.\n, referer: http://rttest.messiah.edu/Admin/CustomFields/

Jason


List info: http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-devel

Drew Barnes
Applications Analyst
Network Resources Department
Raymond Walters College
University of Cincinnati


#6

When I have received this error, I just needed to touch var/log/rt.log

We definitely need to automate that or die at startup.


#7

Drew Barnes wrote:

When I have received this error, I just needed to touch var/log/rt.log

What, this file?
-rw-r–r-- 1 apache root 4620902 2008-05-30 10:40 /opt/rt3/var/log/rt.log

It already exists, and has the correct ownership (I think). I think this
is another problem related to --enable-layout=relative.
Jason


#8

yeah, it’s a problem that ‘relative’ layout brought in.
a temp way to get over:
manually updated RT_Config.pm or RT_Site_Config.pm to set $LogDir to
be absolute.

I’ll try to think about a better way anyway.On May 31, 2008, at 12:06 AM, Jason Long wrote:

Drew Barnes wrote:

When I have received this error, I just needed to touch var/log/
rt.log

What, this file?
-rw-r–r-- 1 apache root 4620902 2008-05-30 10:40 /opt/rt3/var/log/
rt.log

It already exists, and has the correct ownership (I think). I think
this is another problem related to --enable-layout=relative.
Jason

Jason Long wrote:

sunnavy wrote:

I just improved the way of resolving the relative lib path, which
I think can fix the problem you encountered.

check it out :slight_smile:

Thanks. Apache now starts successfully.

However, when I load an RT page in my browser, I get “internal
server error”, and this message in my Apache log file:

[client 10.42.34.240] Log file ‘var/log/rt.log’ couldn’t be
written or created.\n RT can’t run. at /opt/rt3/bin/…/lib/RT.pm
line 300, line 276.\n, referer: http://rttest.messiah.edu/Admin/CustomFields/

best wishes
sunnavy


#9

sunnavy wrote:

yeah, it’s a problem that ‘relative’ layout brought in.
a temp way to get over:
manually updated RT_Config.pm or RT_Site_Config.pm to set $LogDir to
be absolute.

I’ll try to think about a better way anyway.

I’d guess:
when accessing the “LogDir” config option (or any directory-type config
option), concatenate it to $BaseDir unless it’s already an absolute path.
Jason