Skip to main content

Perl Errors

grayloon
Since yesterday, I'm seeing the following error when shelling into one of my cPanel servers. Anyone know what might cause this? Last login: Tue Oct 6 07:52:07 2015 from 192.168.181.32 Attempting to create directory /home/myname/perl5 Unable to create /home/myname/perl5/lib/perl5/5.8.5: No such file or directory at /usr/lib/perl5/site_perl/5.8.8/local/lib.pm line 678. BEGIN failed--compilation aborted. Attempting to create directory /home/myname/perl5 Unable to create /home/myname/perl5/lib/perl5/5.8.5: No such file or directory at /usr/lib/perl5/site_perl/5.8.8/local/lib.pm line 678. BEGIN failed--compilation aborted. Attempting to create directory /home/myname/perl5 Unable to create /home/myname/perl5/lib/perl5/5.8.5: No such file or directory at /usr/lib/perl5/site_perl/5.8.8/local/lib.pm line 678. BEGIN failed--compilation aborted.

Comments

18 comments

Date Votes
  • michaelmcdonald
    Came across this issue yesterday as well. Discovered it had to do with the local/lib.pm module being updated to v2.000017 (which was pushed out yesterday as well). As a temporary fix I copied an older v2.000015 from another server and overwrote the newer one. It corrected the issue, but obviously it's a temporary fix.
    0
  • TomB
    Same here. Started yesterday.
    0
  • cPanelMichael
    Hello :) Internal case CPANEL-1841 is open to address the Perl local::lib errors that occur on CentOS 5 systems after updating to cPanel version 11.50.2. There's currently no specific time frame available on a resolution, but you can monitor our change logs for this case number at:
    0
  • AM2015
    Just a quick note -- I am getting the same error, with CentOS 6 (just so you know that it isn't limited to CentOS 5) All perl-based scripts seem to be functioning normally. Other than the error message, is there any reason for concern? That is, should I try to fix this, or is it safe to ignore for now?
    0
  • Dhaupin
    Confirmed, we are also seeing this with v11.50.2 build 2 on CentOS 6.7 (+Cloudlinux). It shows immediately after login into a user account (not root):
    Attempting to create directory /home/someuser/perl5 Unable to create /home/someuser/perl5/lib/perl5/5.8.8: Permission denied at /usr/local/lib/perl5/site_perl/5.8.8/local/lib.pm line 678. BEGIN failed--compilation aborted. Attempting to create directory /home/someuser/perl5 Unable to create /home/someuser/perl5/lib/perl5/5.8.8: Permission denied at /usr/local/lib/perl5/site_perl/5.8.8/local/lib.pm line 678. BEGIN failed--compilation aborted. Attempting to create directory /home/someuser/perl5 Unable to create /home/someuser/perl5/lib/perl5/5.8.8: Permission denied at /usr/local/lib/perl5/site_perl/5.8.8/local/lib.pm line 678. BEGIN failed--compilation aborted.
    0
  • cPanelMichael
    Instances of this happening on CentOS 6 have been reported to the internal case. The case is still open at this time. You can monitor our change logs for this case number at:
    0
  • gimre
    Hi We are also getting this on an older cpanel (CentOS 5.11, whm 11.30.0 build 29). I know it's an old version, but we cannot upgrade it at this time. Will there be a fix (or maybe a workaround) for it? local::lib is up to date. (2.000017) Thanks!
    0
  • Metro2
    Also happening on RHEL 5, WHM 11.52.0.17 servers
    0
  • Metro2
    I wonder if any of you experiencing this notice the issue I'm posting below also, and if it might be a relevant clue: Home > Service Configuration > Service Manager Startup Log Apr 6 03:23:25.411 [22914] warn: Argument "" isn't numeric in addition (+) at /usr/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/NetSet.pm line 122. Apr 6 03:23:25.411 [22914] warn: oops! unparseable IPv6 address for 127/8: 545803952 at /usr/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/NetSet.pm line 128. Apr 6 03:23:25.412 [22914] warn: oops! unparseable IPv6 address for 127/8: 545804192 at /usr/lib/perl5/site_perl/5.8.8/Mail/SpamAssassin/NetSet.pm line 128. I know it's a long shot that they might be related, but since I've updated past the version that is supposed to contain the fix I'm just digging for clues and seeing what I find in the process.
    0
  • cPanelMichael
    Internal case CPANEL-1841 is still open at this time, and information is added to the case to note the affected versions. There's currently no specific time frame on a resolution, but I will update this thread with more information as it becomes available. Thank you.
    0
  • Skowt
    Also looking for a response on this. We're seeing issues across our infrastructure. Seems to be related to users manually created via commandline (for our case).
    0
  • cPanelMichael
    An autofixer was developed to address this issue and should automatically run once it's released. There's no exact time frame we can provide at this time. Thank you.
    0
  • Dhaupin
    Came across this issue yesterday as well. Discovered it had to do with the local/lib.pm module being updated to v2.000017 (which was pushed out yesterday as well). As a temporary fix I copied an older v2.000015 from another server and overwrote the newer one. It corrected the issue, but obviously it's a temporary fix.

    @michaelmcdonald: is this the same as your older v2.000015 file?
    0
  • Trane Francks
    Hmmm. In our case, I think most (all?) of our server's users were created via the WHMCS / WHM API hooks and we're seeing these perl errors across all SSH logins with the exception of root. If I su from root to another ID, I see the output on the terminal. Manually creating the directory structure clears the error.
    0
  • Dhaupin
    @Trane Francks Who is supposed to be in control of this dir, the user or root? If user, recursive chown lib/perl15 as the user instead of root? The original dir is owned by root and thats why the user isnt able to write ontoith it, at least on our system.
    0
  • Trane Francks
    @Dhaupin: Obviously, the folders in question are created under the individual's account, e.g., /home/myuser/. From a non-root login, /home/'user' folder, running ls -lR shows: perl5/: total 20 drwxr-xr-x 4 living living 4096 Nov 6 04:50 ./ drwx--x--x 37 living living 4096 Nov 10 10:48 ../ drwxr-xr-x 2 living living 4096 Nov 6 04:50 bin/ drwxr-xr-x 3 living living 4096 Nov 6 04:50 lib/ perl5/bin: total 8 drwxr-xr-x 2 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 4 living living 4096 Nov 6 04:50 ../ perl5/lib: total 12 drwxr-xr-x 3 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 4 living living 4096 Nov 6 04:50 ../ drwxr-xr-x 5 living living 4096 Nov 6 04:50 perl5/ perl5/lib/perl5: total 20 drwxr-xr-x 5 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 3 living living 4096 Nov 6 04:50 ../ drwxr-xr-x 3 living living 4096 Nov 6 04:50 5.8.5/ drwxr-xr-x 3 living living 4096 Nov 6 04:50 5.8.8/ drwxr-xr-x 2 living living 4096 Nov 6 04:50 x86_64-linux-thread-multi/ perl5/lib/perl5/5.8.5: total 12 drwxr-xr-x 3 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 5 living living 4096 Nov 6 04:50 ../ drwxr-xr-x 3 living living 4096 Nov 6 04:50 5.8.6/ perl5/lib/perl5/5.8.5/5.8.6: total 12 drwxr-xr-x 3 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 3 living living 4096 Nov 6 04:50 ../ drwxr-xr-x 2 living living 4096 Nov 6 04:50 5.8.7/ perl5/lib/perl5/5.8.5/5.8.6/5.8.7: total 8 drwxr-xr-x 2 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 3 living living 4096 Nov 6 04:50 ../ perl5/lib/perl5/5.8.8: total 12 drwxr-xr-x 3 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 5 living living 4096 Nov 6 04:50 ../ drwxr-xr-x 2 living living 4096 Nov 6 04:50 x86_64-linux-thread-multi/ perl5/lib/perl5/5.8.8/x86_64-linux-thread-multi: total 8 drwxr-xr-x 2 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 3 living living 4096 Nov 6 04:50 ../ perl5/lib/perl5/x86_64-linux-thread-multi: total 8 drwxr-xr-x 2 living living 4096 Nov 6 04:50 ./ drwxr-xr-x 5 living living 4096 Nov 6 04:50 ../ Edited to add: I would be surprised to see any user account folders owned by root. That should never be the case, IMO. User accounts should see all their folders owned by the respective user.
    0
  • Dhaupin
    @Trane Francks Def makes sense. For anyone else having issues: although the suggestion from @michaelmcdonald to rollback into 2.000015 may work, a recursive chown seems easier: First check the users home folder to see what group they're in.
    # ls -l /home/username
    Then recursive chown the perl folder (you prob need to use su/root to do this)
    # chown -R username:usergroup /home/username/perl5
    Log out and in twice (CTRL+D) to see if the error was resolved.
    0
  • Trane Francks
    In our case, all users have correct username/group perms and still see the error. It does not seem to be the causal issue even though there may be correlation.
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post