What could cause the BEGIN block to execute but not the rest of the script without carpout writing anything at all to the log file???
Are you sure the whole script isn't running? Remember, fatal errors are not the only cause of 500 errors on webservers -- so it might be that the whole script is running without dying, but you are still getting a 500 error. It's sounding to me like your 500 error is not coming from a fatal error in your script -- so not because of a die or croak or similar -- but more likely from a mistake in the output of your script; if so, then your fatalsToBrowser or carpout cannot do anything to help you debug.
A quick example of a script that never dies and successfully runs to the end, but still causes a 500 error on the server:
#!/usr/bin/perl use 5.012; # strict, // use warnings; print "Content-Type: text/plain;\n"; # the missing \n will cause a +500 return code, even though your script has no fatal error, and no d +ie print "Hello World\n";
If the problem is in the output of your script (and my guess is in the header section... or that the headers aren't separated by a newline from the content), not in the execution of your script, then you are going to need some way to duplicate the STDOUT output to also go into the logfile of your choice. I know of two ways to do that.
1: If you can install IO::Tee, or can pipe to the tee command on your server, then you should follow the advice in Copy STDOUT and STDERR to logfile and also display to screen for duplicating your STDOUT into your logfile directly.
2: otherwise, you can redirect your script's STDOUT to an in-memory file in a BEGIN block, then at the END, print the contents of that in-memory variable to a logfile and to the original STDOUT handle. Some example code which will run that on my "erroring script" follows in the spoiler:
I put that onto my cPanel-based shared-host website, and loaded it in my browser twice: once with the wrong single \n and once with the right \n\n. The first time, there was a 500 error; the second time, it ran just fine. The dupout.log contained:
... which showed that there weren't enough newlines the first time -- though you have to know enough about the rules for headers vs content to be able derive that from the output.DEBUG 329772 Fri Oct 15 14:06:30 2021: Content-Type: text/plain; DEBUG 329772 Fri Oct 15 14:06:30 2021: Hello World DEBUG 330420 Fri Oct 15 14:06:42 2021: Content-Type: text/plain; DEBUG 330420 Fri Oct 15 14:06:42 2021: DEBUG 330420 Fri Oct 15 14:06:42 2021: Hello World
With that technique, hopefully you can find the difference between a working run and a failing run. (And, like I showed in the example, you should be able to test on your development server, and force a 500 by intentionally creating a bad header, to make sure that the logging is working right and that you've got the printing of the memory block back to the original STDOUT correctly implemented, before trying it live on the server that has the problem.)
In reply to Re^2: Errors uncaught by CGI::Carp
by pryrt
in thread Errors uncaught by CGI::Carp
by Bod
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |