Some errors pertaining to .so files can refer to the file itself, or to a dependency. So if DBD/mysql/mysql.so exists, it could be that it's a dependency that's missing. Maybe the underlying MySQL library was updated and it now has a different name?

Re-installing DBD::mysql should fix the issue. Either that or DBD::mysql is being installed in a "non-standard" location and Perl wasn't told to look there.

No, it said "Can't locate loadable object for" (from DynaLoader), not "Can't load" (from same, but a later stage). See https://github.com/PDLPorters/pdl-linearalgebra/issues/15 for an example, which I'm painfully familiar with in PDL::LinearAlgebra-land.

If I reinstall DBD::mysql am I risking breaking all my running scripts that use it? If those scripts fail, my business would suffer a big loss of income. Most of my billable activities are fed by these scripts. Of the many things I don't understand, why did this just break when there were zero changes on the server? And, why do they all work in html but just not on the command line?

If I reinstall DBD::mysql am I risking breaking all my running scripts that use it? If those scripts fail, my business would suffer a big loss of income. Most of my billable activities are fed by these scripts.

So, you have a broken system, or you may really break your system trying to fix it. In both cases, grab your last verified backup from before the incident and restore it. Problem solved.

If you don't have a backup, then one of these is for you: Kein Backup kein Mitleid / No backup no mercy.

Really, not having a working, verified backup is stupid. Running a business without a working, verified backup is even more stupid. See exhibits A, B, C, D, E.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Are you able to print the contents of @INC on the scripts that are working? Are the scripts that are working and are not working on the same machine?

UPDATE: For example, in your script that is working, right before the use DBD::mysql statement you could insert:

BEGIN {
  open my $fh, ">", "/tmp/name-of-script.INC.txt";
  printf $fh "%s\n", join "\n", @INC;
}
[download]

Also, are the scripts that are working and not working running under the same user?

In each of those three locations check if DBD/mysql/mysql.so exists. If it exists in some but not others, in the paths where it doesn't exist move your mysql.pm to some other name like "mv mysql.pm mysql.pm.save" and see if that fixes it.

find / mysql.so came up empty. File doesn't exist.

Thank you Danny, I'm lost in the threads but all of the scripts run in html and also in the shell except one. Which ran without a problem 15 times. Now, on the 16th try is when the message shows. The server is dedicated and purposely has had zero upgrades because upgrades tend to break things. I tried running as root and also as admin. I think html runs as wheel but I'm not sure. All the scripts are 755 permission. I think the html user is www-data. www-data 31575 0.0 0.3 98448 7588 ? S 06:25 0:08 /usr/sbin/apache2 -k start

Since auto/DBD/mysql/mysql.so seems to be missing you should probably reinstall DBD::mysql. The find/grep should give you a list something like:

/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/auto/DBD/my
+sql
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/auto/DBD/my
+sql/mysql.so
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/auto/DBD/my
+sql/.packlist
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/Bundle/DBD/
+mysql.pm
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/DBD/mysql
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/DBD/mysql/I
+NSTALL.pod
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/DBD/mysql/G
+etInfo.pm
/.../5.38.0/lib/site_perl/5.38.0/x86_64-linux-thread-multi/DBD/mysql.p
+m
[download]

I understood, but auto/DBD/mysql/mysql.so doesn't seem to be there according to your find/grep. Thus, you should probably try to reinstall DBD::mysql.