Perl error: Cant locate strict.pm: Permission denied (due to additional shared libraries path)

Written by - 0 comments

Published on - last updated on January 5th 2024 - Listed in Perl Linux


While testing the monitoring plugin check_mem.pl on a couple of servers, I came across a Perl error on one particular RHEL9 server:

[ck@linux ~]$ /usr/lib64/nagios/plugins/check_mem.pl
Can't locate strict.pm:   /usr/local/share/perl5/5.32/strict.pm: Permission denied at /usr/lib64/nagios/plugins/check_mem.pl line 28.

Usually the "Can't locate xyz.pm" error message points to a missing Perl module. But strict.pm (coming from use::strict inside the Perl script) comes bundled with Perl itself and is not part of a module. So why would the script fail to locate strict.pm?

A different path

After a closer look at the error message, I became aware of the path /usr/local/share/ - which is usually used by self-compiled programs and not by package installations (applies to Debian-based and Enterprise Linux-based systems).

And it really turned out that a perl5 directory resided inside that /usr/local/share path, with restricted permissions only readable by root:

[ck@linux ~]$ ls -la /usr/local/share/
total 16
drwxr-xr-x.  2 root root 4096 Aug 10  2021 applications
drwxr-xr-x.  2 root root 4096 Aug 10  2021 info
drwxr-xr-x. 21 root root 4096 Dec 27  2022 man
drwxr-x---.  3 root root 4096 Nov 14 14:03 perl5

Is there anything in it?

[root@linux ~]# cd /usr/local/share/
[root@linux share]# find perl5/
perl5/
perl5/5.32

Nope, only an empty sub-directory 5.32. This can therefore be removed altogether:

[root@linux share]# rm -rf /usr/local/share/perl5/

And with this path gone, Perl is parsing /usr/share/perl5 to find strict.pm (which exists, of course, if Perl is installed). And now check_mem works again:

[ck@linux ~]$ /usr/lib64/nagios/plugins/check_mem.pl
check_mem.pl v1.0 - Nagios Plugin

usage:
check_mem.pl -<f|u|a> -w <warnlevel> -c <critlevel>
[...]

Which paths is Perl using?

As a follow-up on this solved problem, let's find out why Perl was using /usr/local/share/perl5 in the first place. Are there other paths which may have caused the same problem? How can we know which paths Perl is looking for modules?

This answer came as a hint in a social media comment from Kalamata Hari. Perl is able to print the configured "@INC" paths (where it looks for libraries/modules) with the following command: perl -le 'print for @INC'.

On my Linux Mint this shows:

ck@mint ~ $ perl -le 'print for @INC'
/etc/perl
/usr/local/lib/x86_64-linux-gnu/perl/5.34.0
/usr/local/share/perl/5.34.0
/usr/lib/x86_64-linux-gnu/perl5/5.34
/usr/share/perl5
/usr/lib/x86_64-linux-gnu/perl-base
/usr/lib/x86_64-linux-gnu/perl/5.34
/usr/share/perl/5.34
/usr/local/lib/site_perl

The Perl library paths can also be appended or replaced altogether. There are multiple possibilities to set this as a Bash variable (export PERL5LIB=/path/to/modules) or inside a Perl script using "use lib '/path/to/modules'".


Add a comment

Show form to leave a comment

Comments (newest first)

No comments yet.

RSS feed

Blog Tags:

  AWS   Android   Ansible   Apache   Apple   Atlassian   BSD   Backup   Bash   Bluecoat   CMS   Chef   Cloud   Coding   Consul   Containers   CouchDB   DB   DNS   Database   Databases   Docker   ELK   Elasticsearch   Filebeat   FreeBSD   Galera   Git   GlusterFS   Grafana   Graphics   HAProxy   HTML   Hacks   Hardware   Icinga   Influx   Internet   Java   KVM   Kibana   Kodi   Kubernetes   LVM   LXC   Linux   Logstash   Mac   Macintosh   Mail   MariaDB   Minio   MongoDB   Monitoring   Multimedia   MySQL   NFS   Nagios   Network   Nginx   OSSEC   OTRS   Office   PGSQL   PHP   Perl   Personal   PostgreSQL   Postgres   PowerDNS   Proxmox   Proxy   Python   Rancher   Rant   Redis   Roundcube   SSL   Samba   Seafile   Security   Shell   SmartOS   Solaris   Surveillance   Systemd   TLS   Tomcat   Ubuntu   Unix   VMWare   VMware   Varnish   Virtualization   Windows   Wireless   Wordpress   Wyse   ZFS   Zoneminder