-1

Problem:

Errors generated by Perl scripts are not displayed or logged in an Azure web application.

Steps to reproduce:

  • Install Strawberry Perl to an Azure web application, using this guide.

    The most relevant part of that guide being that I have Perl configured as a handler for the .pl extension, using perl.exe with an argument of -MFCGI::IIS=do.

  • Enable logging to local file system (error level: verbose).

  • Enable detailed error messages and Failed Request Tracing.

  • Run the following test script in a browser:

    
    use strict;
    use warnings;
    use diagnostics;
    use CGI::Carp 'fatalsToBrowser';
    
    use CGI;
    my $q = new CGI;
    print $q->header(-type => "text/plain");
    
    print "Hello, World!\n";
    
    die "This is a test";
    
    print "End of script.";
    

My results:

  • Script halts after "Hello, World!" ("End of script" and "This is a test" are not displayed).

  • "This is a test" is not found in any log file in the /LogFiles directory.

Things I have Verified

  • Strawberry Perl runs when executed via the command line (using Kudu).

  • When run using the command line, the script produces expected results:

    [Thu Mar 10 16:09:30 2016] azure-test.pl: This is a test at d:\home\site\wwwroot\cgi-bin\azure-test.pl line 12.
    Content-Type: text/plain; charset=ISO-8859-1
    
    Hello, World!
    <h1>Software error:</h1>
    <pre>This is a test at d:\home\site\wwwroot\cgi-bin\azure-test.pl line 12.
    </pre>
    <p>
    For help, please send mail to this site's webmaster, giving this error message 
    and the time and date of the error.
    
    </p>
    

Why Can't I Just use Perl to View the Errors?

A different section of code is failing in Azure, but not in Perl. I need to see the errors generated in the Azure environment in order to troubleshoot it.

AaronSieb
  • 8,106
  • 8
  • 39
  • 58
  • 1
    You are using `print` where `warn` or `die` is called for. Second, you are sending headers twice. Third, this is probably related to your web server set up more than anything else. Find where the logs are, find out what you are choosing to log. – Sinan Ünür Mar 08 '16 at 16:43
  • @SinanÜnür 1. Production code uses `die`, `print` used here because I could confirm that `print` statements used elsewhere in the script worked. Amended to `warn`; no change in behavior. 2. Removed header print statement; no change in behavior. 3. I've indicated where I'm looking for the logs in Azure (and my log settings). If there is a different location where these errors are being logged, that would be acceptable as an answer. – AaronSieb Mar 08 '16 at 16:57
  • So I'm getting down votes and close votes... Is Azure configuration off-topic for SO? And if so, where is a better place to post such questions? – AaronSieb Mar 10 '16 at 13:58
  • You did not post a short and complete script that demonstrates the problem. You need to isolate the issue from the all the confounding factors you have introduced. The close votes are for "too broad" ... that is, "given the vague and incomplete description, there are so many things that could be wrong that it is not worth the bother". You can choose to help others help you. It is up to you. – Sinan Ünür Mar 10 '16 at 15:42
  • @SinanÜnür I have reorganized the question, and reduced the reproduction steps to the minimum. Is this better? – AaronSieb Mar 10 '16 at 16:19

1 Answers1

0

Errors can be sent to the browser by adjusting the additional arguments to the handler mapping for the *.pl extension.

In particular, -MFCGI::IIS=eval worked for me.

See the documentation.

Note that some errors still aren't reported in the browser. For example, there appears to be an issue with DBI database calls that causes the process to halt without displaying the error message.

These errors can be viewed using Failed Request Tracing.

Failed Request Tracing can be enabled under All Settings -> Diagnostic Logs -> Failed Request Tracing

The resulting logs are accessible via FTP at /LogFiles/W3SVC*/fr*.xml .

To view the files, download the XML file for your request, along with freb.xsl from the same directory. You can then view the log XML file in an XML viewer (such as Internet Explorer).

More information:

AaronSieb
  • 8,106
  • 8
  • 39
  • 58