DateTime/Set.pm not found in @INC

RT Users
1

Alle,

I've just installed RTx-Calendar and restarted httpd, which resulted in

this error, even though DateTime/Set.pm is in perl’s @INC path:

[cwfox@admin-new perl]$ pwd
/opt/perl
[cwfox@admin-new perl]$ /opt/perl/bin/perl -le ‘print foreach @INC’
/opt/perl/lib/site_perl/5.16.2/x86_64-linux
/opt/perl/lib/site_perl/5.16.2
/opt/perl/lib/5.16.2/x86_64-linux
/opt/perl/lib/5.16.2
.
[cwfox@admin-new perl]$ find . -name Set.pm | grep DateTime
./lib/site_perl/5.16.2/DateTime/Set.pm
[cwfox@admin-new perl]$ sudo service httpd start
Starting httpd: [Sat Feb 23 23:38:57 2013] [warning]: (in cleanup)
Error while loading /opt/rt4/sbin/rt-server: Can’t locate
DateTime/Set.pm in @INC (@INC contains: /opt/rt4/sbin/…/local/lib
/opt/rt4/local/plugins/RT-Extension-Gravatar/lib
/opt/rt4/local/plugins/RT-Extension-HistoryFilter/lib
/opt/rt4/local/plugins/RT-Extension-SLA/lib
/opt/rt4/local/plugins/RT-Extension-SummaryByUser/lib
/opt/rt4/local/plugins/RTx-EmailCompletion/lib
/opt/rt4/local/plugins/RTx-Calendar/lib /opt/rt4/sbin/…/lib
/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 . /etc/httpd) at
/opt/rt4/local/plugins/RTx-Calendar/lib/RTx/Calendar.pm line 5.
BEGIN failed–compilation aborted at
/opt/rt4/local/plugins/RTx-Calendar/lib/RTx/Calendar.pm line 5.
Compilation failed in require at /opt/rt4/sbin/…/lib/RT.pm line 686.
(/opt/rt4/sbin/…/lib/RT.pm:358)
httpd: Could not reliably determine the server’s fully qualified domain
name, using admin-new.subaru.nao.ac.jp for ServerName
[ OK ]
[cwfox@admin-new perl]$

Can anyone tell me how to fix this without resorting to adding the

site_perl to the path?

Best Regards,
Camron

Camron W. Fox
Hilo Office
High Performance Computing Group
Fujitsu Management Services of America, Inc.
E-mail: cwfox@us.fujitsu.com

2

Are you sure that this perl /opt/perl/bin/perl

[cwfox@admin-new perl]$ /opt/perl/bin/perl -le ‘print foreach @INC’
/opt/perl/lib/site_perl/5.16.2/x86_64-linux
/opt/perl/lib/site_perl/5.16.2
/opt/perl/lib/5.16.2/x86_64-linux
/opt/perl/lib/5.16.2

Is the same as this perl?

/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 . /etc/httpd) at

It looks like RT is running under /usr/bin/perl (the system perl) and
anything you install into your custom perl will be unavailable.

Disable the calendar plugin and start up RT and visit the System
Configuration page to compare the perl -V output at the bottom to the
results of /usr/bin/perl -V and /opt/perl/bin/perl -V

Keep in mind, if you’re using a packaged mod_perl you’re almost
certainly not using your custom built perl.

-kevin

3

Are you sure that this perl /opt/perl/bin/perl

[cwfox@admin-new perl]$ /opt/perl/bin/perl -le ‘print foreach @INC’
/opt/perl/lib/site_perl/5.16.2/x86_64-linux
/opt/perl/lib/site_perl/5.16.2
/opt/perl/lib/5.16.2/x86_64-linux
/opt/perl/lib/5.16.2

Is the same as this perl?

/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 . /etc/httpd) at

It looks like RT is running under /usr/bin/perl (the system perl) and
anything you install into your custom perl will be unavailable.

Disable the calendar plugin and start up RT and visit the System
Configuration page to compare the perl -V output at the bottom to the
results of /usr/bin/perl -V and /opt/perl/bin/perl -V

Keep in mind, if you’re using a packaged mod_perl you’re almost
certainly not using your custom built perl.

-kevin

Kevin,

/opt/perl/bin/perl and all the permods were installed specifically for

this RT installation.

I installed perl 5.16.2 in /opt/perl and used it as the perl to install

everything, so how (and when) did the RT instance get hijacked?

This pretty much sucks.

Best Regards,
Camron

Camron W. Fox
Hilo Office
High Performance Computing Group
Fujitsu Management Services of America, Inc.
E-mail: cwfox@us.fujitsu.com
Phone: (808) 934-4102
Cell: (808) 937-5026

4

Are you sure that this perl /opt/perl/bin/perl

[cwfox@admin-new perl]$ /opt/perl/bin/perl -le ‘print foreach @INC’
/opt/perl/lib/site_perl/5.16.2/x86_64-linux
/opt/perl/lib/site_perl/5.16.2
/opt/perl/lib/5.16.2/x86_64-linux
/opt/perl/lib/5.16.2

Is the same as this perl?

/usr/local/lib64/perl5 /usr/local/share/perl5
/usr/lib64/perl5/vendor_perl /usr/share/perl5/vendor_perl
/usr/lib64/perl5 /usr/share/perl5 . /etc/httpd) at

It looks like RT is running under /usr/bin/perl (the system perl) and
anything you install into your custom perl will be unavailable.

Disable the calendar plugin and start up RT and visit the System
Configuration page to compare the perl -V output at the bottom to the
results of /usr/bin/perl -V and /opt/perl/bin/perl -V

Keep in mind, if you’re using a packaged mod_perl you’re almost
certainly not using your custom built perl.

/opt/perl/bin/perl and all the permods were installed specifically for
this RT installation.

I installed perl 5.16.2 in /opt/perl and used it as the perl to install
everything, so how (and when) did the RT instance get hijacked?

This pretty much sucks.

Are you using mod_perl from the system distribution?
If so, it’s going to use the system perl

If so, you need to either use fastcgi or build mod_perl against your
custom perl (which is nowhere near as hard as it was years ago,
thankfully).

Since you have a custom perl, you should keep in mind this
announcement we made earlier today.

-kevin