Just omitting CGI::Carp and just using plain old Carp should do the trick. Carp behaves nicely and writes all errors to STDERR, where they belong. The web server collects STDERR output and writes that to its error log. Problem solved, even when multiple CGIs are running concurrently (which might create nasty races when trying to write to a common log file at the CGI level). That also works when your CGI has a really bad day and just crashes before Carp or CGI::Carp can do their work.

The only remaining problem might be the hoster: Some really cheap hosters prevent you from reading your server's error log. That really sucks, and cannot be solved completely at the application (CGI) layer. If that is the case, consider changing the hoster or upgrading to a contract with access to the error log.

Alexander

Just omitting CGI::Carp and just using plain old Carp should do the trick

It's late here so a quick test before I head to bed...
I've changed from CGI::Carp to Carp in the script that gives the 500 error as suggested. Of course it makes no difference to the way the script behaves. But also, it doesn't write anything to the cPanel error log.

The only remaining problem might be the hoster: Some really cheap hosters prevent you from reading your server's error log

I've never been entirely sure what the cPanel error log actually is so I have dived into the documentation to find out. Its says "The interface includes entries in the /usr/local/apache/logs/suexec_log file and the /usr/local/apache/logs/error_log file"

Not knowing a great deal about the inner workings of Apache and cPanel, it looks to me like the latter will be the right error log file where these sorts of errors should be written. Certainly lots of "File does not exist" errors get written there along with a few Perl warnings and the odd MariaDB error.

The script I am calling gets listed in the suEXEC log but the one that it calls (the one with the error) does not.