Re: Errors uncaught by CGI::Carp

The bit I am most confused about is that my understanding is that, with fatalsToBrowser the only two ways to get a 500 error is that the script has the wrong permissions or that the script doesn't return valid HTTP headers. As this is an intermittent problem, it is neither of these.

That is a bit of a non-sequitur. There are many ways for a script not to return valid HTTP headers in an intermittent way. The most obvious one is an intermittent restriction of some O/S level resource: open files, available RAM, etc.

But the errors are not written to the Apache error log

They certainly should be. Are you still running on shared hosting? If so, the real error log is unlikely to be accessible to you as it will (in the case of the event or worker MPM) contain data relevant to any and all of the sites on that shared server. Perhaps have a word with your hoster to see if they can at least give you some of the data which is relevant just to your site. Further, you might consider this as yet another reason to make the move to a VM/VPS instead.

🦛

Comment on Re: Errors uncaught by CGI::Carp

Replies are listed 'Best First'.
Re^2: Errors uncaught by CGI::Carp by Bod (Parson) on Oct 15, 2021 at 23:11 UTC
The most obvious one is an intermittent restriction of some O/S level resource: open files, available RAM, etc. Once again hippo you seem to have identified the issue when everything tells me it cannot be that! Note to self - always listen to hippo's wisdom regardless of how I am interpreting the evidence differently. Digging deep into cPanel where I've never needed to go before, I have found a graph of CPU usage over the last 24 hours. It shows an error state several times during that time period. The last time roughly corresponds with the last 500 error I got from the site... So, perhaps the reason I don't see errors on other sites is because this site is doing something much more CPU intensive than the other sites. Some of the other sites get much more traffic. Therefore I have been thinking what is different on this site to any of the other: Perl is in taint mode The database has tables with spatial data types The file structure is laid out differently so modules are above the webroot Scripts are called by the Apache default handler AJAX is used to deliver (sometimes large) JSON files to the browser for Google/Bing maps APIs Other than that, there are no major differences that I can think of. There are less scripts than most other sites and they are laid out better as they were planned out more thoroughly before any code was written. Nothing has been written that I would expect to be especially resource intensive - there are no big sorts or especially complex maths. It has to be something that is common to all the scripts as the 500 errors are not limited to always the same script. So modules or something external like the database or the connection to Facebook. you might consider this as yet another reason to make the move to a VM/VPS instead Yes indeed. This site is a commercial venture that is starting to bring in revenue. I see it as the generator of the funds to enable me to upgrade web services to use across all the businesses and sites. Everything is a bit crazy right now and having time to properly move forward with a hosting upgrade would be wonderful.	[reply]
Re^2: Errors uncaught by CGI::Carp by Bod (Parson) on Oct 14, 2021 at 17:30 UTC
There are many ways for a script not to return valid HTTP headers in an intermittent way. The most obvious one is an intermittent restriction of some O/S level resource: open files, available RAM, etc. Good point as usual hippo. However, the examples you give would cause the other sites hosted on the same machine, including the test site for this domain, to give random error. They don't - or at least I have not experienced them. It is possible that they do as it is an intermittent problem but it seems unlikely that I would only notice it on one site and no others. Are you still running on shared hosting? If so, the real error log is unlikely to be accessible to you... Yes, it is on shared hosting with cPanel According to the cPanel documentation, the error log I can see comes from `/usr/local/apache/logs/error_log`.	[reply] [d/l]
Re^3: Errors uncaught by CGI::Carp by hippo (Bishop) on Oct 14, 2021 at 21:42 UTC
Not all resource limits are global. At $WORK we impose per-user limits (effectively per-site limits) on our shared hosting customers precisely so that one poorly-written or heavily-hit site doesn't adversely impact upon the rest. I would expect every other shared hoster to implement something similar. This would explain why you only see it in production - that site will (hopefully) receive orders of magnitude more traffic than your test/demo site. 🦛	[reply]
Re^4: Errors uncaught by CGI::Carp by Bod (Parson) on Oct 14, 2021 at 22:01 UTC
I am sure there are per-user resource limits. In fact I know there are because the host documents then. But I'd assumed they would cover all my sites within the same account. I have a hosting account with add-on domains. Both the production and test sites are add-on domains and there are others. One of the others gets much more traffic than the one that is generating errors - sometimes up to 50 times more traffic when we have some ad campaigns running and they don't give an error. I've checked the bandwidth logs and we never go above 15% of the allowance.	[reply]
Re^4: Errors uncaught by CGI::Carp by Bod (Parson) on Oct 14, 2021 at 22:38 UTC
Not all resource limits are global. At $WORK we impose per-user limits At $work do you throw a 500 error if a user exceeds their resources or do you send something more informative to the browser?	[reply]
Re^5: Errors uncaught by CGI::Carp by hippo (Bishop) on Oct 15, 2021 at 08:32 UTC


Perl: the Markov chain saw
	PerlMonks