Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:

Well after much hacking around and poking things, I finally got my Everything code site working. All was good with the world, then some SOB coworking unceremoniously shut my box down(long story).

My problem now is this: When initially installing everything on my redhat system, I discovered that CPAN had installed all of the modules into paths starting with /usr/local/lib/ instead of /usr/lib. Also these /usr/local paths had 5.6.1 in them instead of 5.6.0 and i686-linux instead of 1386-linux. What I did to remedy this problem at the time of initial setup was merely to:

export PERL5LIB='/usr/local/lib/perl5/5.6.1/i686-linux
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux
/usr/local/lib/perl5/site_perl/5.6.1 /usr/local/lib/perl5/site_perl'

I then started my /etc/init.d/http and everything was fine and dandy. Now, since I was lazy, I hadn't added these paths to my /etc/profile, they were only added to that terminal session. So when my computer was so inconveniently rebooted, the httpd startup script did not have these variables in the path and so it failed to start.

So now I go and properly add the new paths to my /etc/profile this time, but when I try to start httpd I get this:

Starting httpd: Syntax error on line 904 of /etc/httpd/conf/httpd.conf: Can't locate Apache/DBI.pm in @INC (@INC contains: /usr/local/lib/perl5/5.6.1/i686-linux
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/i686-linux
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
/usr/lib/perl5/5.6.0/i386-linux
/usr/lib/perl5/5.6.0
/usr/lib/perl5/site_perl/5.6.0/i386-linux
/usr/lib/perl5/site_perl/5.6.0
/usr/lib/perl5/site_perl
. /etc/httpd/ /etc/httpd/lib/perl) at (eval 4) line 3. FAILED

Now, I've gone through the paths several times and checked to make sure the paths were correct, with no typos. The error messages lists all of the correct paths that I want it to see, but I have no idea why it can't find the DBI file. Even stranger to me is that I moved the actual file to an apprpriate place in the OLD set of paths and it found it fine. Normally I would let that be my solution, except that I would need to move all of the PM's to these directories, since DBI.pm was not able to find other files that IT needed in it's new location. Any help on this would be greatly appreciated.

Replies are listed 'Best First'.
Re: Problems with environment variables.
by chipmunk (Parson) on Aug 16, 2001 at 01:55 UTC
    Er... If CPAN.pm installed the modules in /usr/local/lib in subdirectories named 5.6.1 and i686-linux, it's because the perl that was used was 5.6.1, configured for /usr/local/lib and i686-linux. So, instead of messing around with @INC, why don't you just use the same perl executable that was used to install the modules?
[reply]
      How would be the best way to do that? Please be detailed as I am relatively new linux adminstration :) Brian
[reply]
        First, you should find all the executables on your system named perl. The most likely places are /usr/bin/perl and /usr/local/bin/perl. Check the directories in your path (`echo $PATH`) for other executables named perl. (If you're on Linux, you could use `locate` to find any outside your path. `locate -r /perl\$` [This will find directories named perl also.])

        Once you've found all the perl executables, check their versions. /usr/bin/perl -v will tell you the version of the perl executable in /usr/bin; usr/bin/perl -V will tell you the configuration details as well, including the values in @INC. Figure out which executable is the right version and points to the right directories in @INC.

        When you find the perl you want to use, let's say /usr/local/bin/perl, you probably want to rename the others. For example, if /usr/local/bin/perl is 5.6.1, and /usr/bin/perl is 5.6.0, rename /usr/bin/perl to perl5.6.0, and replace it with a link to the main perl: `ln -s /usr/local/bin/perl /usr/bin/perl`. However, you should make sure that scripts using /usr/bin/perl will continue to work after the switch to /usr/local/bin/perl. You can skip this step if you're unsure.

        Now that you know you want to use /usr/local/bin/perl with the specific script that started this process, open the script in your editor and make sure the first line in #!/usr/local/bin/perl. If it's a web script, make sure your server is configured to use /usr/local/bin/perl to execute Perl scripts.

        I hope that's helpful!

[reply]
Re: Problems with environment variables.
by cLive ;-) (Prior) on Aug 16, 2001 at 08:33 UTC
    add the line: 
    use lib '/usr/local/lib/perl5';

    [download]
    to the top of each script. I think that will work. You may need to add the rest of the directories, but I don't remember having to add sub-directories when i had to do it...

    cLive ;-)

[reply]
[d/l]
Re: Problems with environment variables.
by mugwumpjism (Hermit) on Aug 16, 2001 at 02:14 UTC

    ...use the strace(1), Luke... use the strace(1)...

    You HAVE checked the file and directory access permissions, haven't you?

[reply]
      Could you please explain? I have no clue what strace(1) is. Sorry for being a perl/linux newbie :) please bear with me. Brian
[reply]

        Basically, if you run strace -o logfile program, it will run "program", logging all of it's system calls to the file "logfile". It mostly looks like incomprehensible garbage, as there are many system calls you don't care about. But you will also be able to see file accesses, in particular where apache tries to look for the library in question (search for the name of the module, you will see something like a "stat" or an "access" call foreach (@INC)). All of the system calls being made should have man pages - usually in section 2 (eg "man 2 fstat"), although you may need relevant "development" packages for your C library for this to work (the package is called manpages-dev under Debian, but could be something like libc6-dev).

        If you want to trace a daemon, you should give strace a few extra options (see the man page). Replacing a call to "httpd" with "strace -fae -o /tmp/strace.$$ httpd" wouldn't be a bad call.

        There are likely to be simpler ways to help with this particular problem, but in general if something is misbehaving and you don't have a clue why, strace can come to the rescue.

[reply]

Back to Seekers of Perl Wisdom