The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at webmaster@moonpoint.com to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
I then found that any blog article I attempted to access produced the same results, so I looked at the last few entries in the error log for the site with the tail command. I saw the following entries:
[Fri Apr 22 10:35:37.340759 2016] [cgi:error] [pid 13080] [client 207.241.237.22 9:55655] A non well formed numeric value encountered: blosxom, referer: http:// support.moonpoint.com/blog/blosxom [Fri Apr 22 10:36:54.281534 2016] [cgi:error] [pid 12097] [client 46.105.101.55: 32992] AH01215: Magic number checking on storable file failed at /usr/lib64/perl 5/vendor_perl/Storable.pm line 381, <DATA> line 32, at /home/jdoe/public_html/su pport/blog/plugins/calendar line 322. [Fri Apr 22 10:36:54.313533 2016] [cgi:error] [pid 12097] [client 46.105.101.55: 32992] End of script output before headers: blosxom [Fri Apr 22 10:38:22.188487 2016] [cgi:error] [pid 12097] [client 207.46.13.172: 13418] AH01215: Magic number checking on storable file failed at /usr/lib64/perl 5/vendor_perl/Storable.pm line 381, <DATA> line 32, at /home/jdoe/public_html/su pport/blog/plugins/calendar line 322. [Fri Apr 22 10:38:22.219964 2016] [cgi:error] [pid 12097] [client 207.46.13.172: 13418] End of script output before headers: blosxom [Fri Apr 22 10:38:48.950200 2016] [:error] [pid 13081] [client 36.83.154.209:270 18] PHP Notice: A non well formed numeric value encountered in /home/jdoe/publi c_html/support/template/footer.php on line 31, referer: https://www.google.com [Fri Apr 22 10:38:57.884346 2016] [cgi:error] [pid 13080] [client 207.255.181.21 0:2112] AH01215: Magic number checking on storable file failed at /usr/lib64/per l5/vendor_perl/Storable.pm line 381, <DATA> line 32, at /home/jdoe/public_html/s upport/blog/plugins/calendar line 322., referer: https://www.google.com [Fri Apr 22 10:38:57.917660 2016] [cgi:error] [pid 13080] [client 207.255.181.21 0:2112] End of script output before headers: blosxom, referer: https://www.googl e.com [Fri Apr 22 10:39:22.635493 2016] [cgi:error] [pid 16723] [client 164.132.161.23 :53167] AH01215: Magic number checking on storable file failed at /usr/lib64/per l5/vendor_perl/Storable.pm line 381, <DATA> line 32, at /home/jdoe/public_html/s upport/blog/plugins/calendar line 322. [Fri Apr 22 10:39:22.683037 2016] [cgi:error] [pid 16723] [client 164.132.161.23 :53167] End of script output before headers: blosxom
Since the entries pointed to an issue linked to the Perl module Storable.pm, but which was being triggered by line 322 of the calendar plugin for the Blosxom blog software I use on the system, I checked line 322 in the calendar plugin:
$cache = (-r $cachefile ? Storable::lock_retrieve($cachefile) : undef);
The line is part of the following block of code:
if (!Storable->can('lock_retrieve')) {
debug(1, "cache disabled, Storable::lock_retrieve not available");
$use_caching = 0;
return 0;
}
$cache = (-r $cachefile ? Storable::lock_retrieve($cachefile) : undef);
# >= rather than ==, so that if we're being used along with a search
# plugin that reduces %files, rather than dumping the cache and showing
# a limited calendar, we'll display the full thing (if available) . I
# think that's preferable as well as being more efficient.
# XXX improvement: rather than dumping the whole thing, just update the
# count and dump the current month (and sometimes the previous month
# and year)I checked the cache file being used by the calendar plugin and found it was zero bytes in length.
$ ls -al ~/public_html/support/blog/plugins/state/.calendar.cache -rw-r--r--. 1 apache apache 0 Apr 22 04:11 .calendar.cache
So I deleted the file, which should not have been a zero-byte file. It will be recreated automatically after it is deleted.
[root@support blog]# rm plugins/state/.calendar.cache rm: remove regular empty file `plugins/state/.calendar.cache´? y [root@support blog]# ls -al plugins/state/.calendar.cache -rw-r--r--. 1 apache apache 71121 Apr 22 10:49 plugins/state/.calendar.cache
After I deleted the file and it was recreated, I did not experience the problem again. Checking prior blog postings, I found that I experienced the same problem on March 22, 2016, i.e., the same day of the month last month, which I noted in Blosxom - Magic number checking on storable file failed.