Keith's Software and Tutorials Home Page
Knowledge Is Power

Bestdam Website Visitor Logger
+ Hit Counter

Troubleshooting   Problems









Home

How Do I CGI ?

BDL Features

BDL Download

BDL Setup

Quick Setup

BDL Windows

BDL Help

BDL How To

BDL Log Tips

Hit History

BDL Duo

BDL Upgrade

Don't get all bummed out if the script doesn't work the first time. With so many different brands of server operating system software and Web-server software available, and each of them having a myriad of configuration options, there are a gazillion different Web environments out there. As a result, you may have to make a few adjustments to the script to get things working. Below are some of the most common problems you could encounter and some possible fixes and suggestions for trying to track down the problem.


The three most likely problems you will encounter when trying to execute a script are:

  1. The Web page containing the SSI directive displays OK but the script doesn't seem to be doing anything at all.

    Usually this is related to file permissions or paths.
  2. The Web page containing the SSI directive displays OK but you see the message "An error occurred processing this directive" on the page where the SSI directive tag is located.

    The most common cause of this error is something (the path or script file name) being mis-spelled in the directive tag.
  3. Instead of the your Web page being displayed you see an error page that says "Internal server error".

    The most common cause of this is a bad shebang line.

The three things you can do to try and determine what is happening are:

  1. If it appears the server is not running the script, and you're not getting the "internal server error" page, display the page containing the SSI directive tag in your browser and view the page's source listing (on your browser's menu bar select View/Source with IE or View/Page Source with Netscape).

    • If the SSI directive tag does show up in the page source listing it is not being processed by the server.
    • If the SSI directive tag does not show up, it is being processed by your server.

      (See the Possible Causes sections below for each one of the above.)


  2. ftp into your server and check the date and time of the script's data files (pagehits.cnt, period.log) and see if the date and time on either file is changing (coinciding with the time you tried to load the page).

    • if they are, the server is at least trying to execute the script.
    • if they are not, the server may not even be trying to execute the script.


  3. Look at your server's error logs for any entries with a date and time that match that of when you tried to run the script. If there are any, check for error message in those entries that may give a clue as to what the problem is.

    Note:  If you don't have access to your error logs, but you do have telnet capability:
    1. Telnet into your server.
    2. Go into the directory that contains the script.
    3. At the shell prompt type in bdlogger.pl to execute the script and look at any error messages.

      If your are getting the text of "Internal server error" page displayed, at the shell prompt try typing in perl bdlogger.pl to see if the script runs without errors. If it does run OK, the problem is the "shebang line" (the first line in the script that is your Perl path).


Possible Causes - The SSI tag is visible in your page source
  • verify you have CGI capability with your ISP/host

  • verify you have SSI capability with your ISP/host

  • if your page does not have a .shtml extension try renaming the file to change the extension to .shtml and open the page directly in your browser (i.e. don't use a link on another page to go to it)

  • make sure that the <!--#exec characters in the first part of the SSI directive tag are all together - i.e. no spaces (see the tag in Step 4 of the Setup & Installation page)

  • make sure that there is a space in the " --> characters near the end of the tag (see the tag in Step 4 of the Setup & Installation page)

  • see if your ISP/host requires that pages containing SSI directives have an .shtml or .shtm extension


Possible Causes - The SSI tag is not visible in your page source
(may get the "An error occurred processing this directive" displayed on the page)
  • UNIX/Linux is case sensitive so make sure the names of all files are lower-case once they are trasferred to your server and verify the file name in the SSI directive tag is lower-case

  • verify the SSI directive tag is in the page you are viewing (by using your HTML editor to look at the file on your local hard-drive - never assume)

  • if you are not absolutely sure you transferred the script and data files in ASCII mode, re-transfer them using ASCII mode

  • verify all five of the required Bestdam Logger files are in the BDLOGGER directory

  • verify the permissions for the files are set correctly as outlined on this site's "How To...." page

  • If you are using the Deluxe edition, and you have the either of the two Web-page options enabled, disable them and see if the script works. If it does, it indicates that the system paths you specified for the Web-page files are incorrect.

  • see if your ISP/host requires that scripts have a .cgi extension

  • see if your ISP/host requires the use of a relative path in the tag such as

    <!--#exec cgi="cgi-bin/bdlogger/bdlogger.pl" -->
    instead of
    <!--#exec cgi="/cgi-bin/bdlogger/bdlogger.pl" -->

  • For the Deluxe edition, if you have telnet access:

    1. Telnet into your server.
    2. Go into the directory that contains your Web pages
    3. At the shell prompt type in pwd to display the system path to your Web pages and make sure this is the path you have entered for the Web page variables in the script.


Possible Causes - You get the "Internal server error" page displayed

While just about anything could cause this dreaded page to appear, the most common cause is a bad shebang line (the first line in the script that is the path to Perl). However I have seen other problems, such as a missing file, cause this error page to appear. Try using the alternate Perl path. i.e. if you're using

#!/usr/bin/perl     (often the Perl 4 location)

try

#!/usr/local/bin/perl     (often the Perl 5 location)

or visa-versa. Note that a shebang line should not be necessary on NT servers.


Possible Causes - The hit counter is not displayed but the period.log file is being updated
  • view the BDLOGGER.PL file to make sure you have $display_count = 1; in the optional variables (see below)

  • view the BDLOGGER.PL file to make sure you have $count_hits = 1; in the optional variables (see below)



Possible Causes - You get an error message that says "Could not OPEN xxxx file"

The "xxxx" could be "trigger" which would indicate the trigger.dat file, or "count" which would be the pagehits.cnt file, or "log" which would be the period.log file. This would indicate that either the specified file is not in the same directory as the bdlogger.pl file, the permissions on the specified file are not set correctly, or the specified file was not transferred in ASCII mode.



Possible Causes - Broken graphics symbol where graphics counter digits should be   (Deluxe edition only)

The correct path is not entered in the $digits_path variable.



Possible Causes - If the Web pages are not being created   (Deluxe edition only)

  • make sure you have the $make_page and/or $web_report variables set to 1

  • verify with your host or ISP that the system path your have entered for the $page_path and/or $report_path variables is correct


Possible Causes - If you do not receive an e-mail report

  • the most likely cause is that none of the pages being monitored has been "hit" (viewed) since the day change

  • if the pages have been "hit":

    • view the BDLOGGER.PL file to make sure you have $mail_report = 1;  (or 2 with the Deluxe edition) in the optional variables (see below)

    • verify the name and path of the server-based e-mail program with your host or ISP

    • verify that you have the server-based e-mail program name and path entered correctly, and within the single quote marks, in BDLOGGER.PL file

    You can also try using the small script below to test your e-mail functionality. To use this script:

    1. Highlight the script text below and copy it to your clipboard.
    2. Paste the script text into Notepad or some other text editor.
    3. Enter the correct values for the shebang line and the $sendto and $mailprgm variables.
    4. Save the file as testmail.cgi
    5. ftp (ASCII) the testmail.cgi file into your cgi-bin directory and CHMOD it as 755
    6. Run the script using your browser by enter the correct URL in the location line. For example:

      http://www.mydomain.com/cgi-bin/testmail.cgi

      A page should be displayed saying that a test e-mail was sent to your domain. Shortly thereafter, you should receive the test e-mail message. Here is the text of the script.


#!/usr/local/bin/perl
print "Content-type: text/html\n\n"; 

# E-mail Testing Script for UNIX/Linux Servers

#  ENTER CORRECT VALUES FOR THESE TWO VARIABLES
$sendto = 'me@mydomain.com';             # Recipient E-mail address
$mailprgm = '/usr/lib/sendmail -t';      # Path to mail program

$sitename = $ENV{'SERVER_NAME'};

open (MAIL, "|$mailprgm") || die "Can't open mail program\n";
print MAIL "To: $sendto\n";
print MAIL "Subject: Test Mail from $sitename \n\n";
print MAIL  "\nSending test e-mail from a CGI script on $sitename\n\n";
close MAIL;

print "\n\nTest e-mail message sent to $sendto\n\n";

exit;



Top of page




Powered by Apache On Debian Linux


Contents, diagrams, and images    Copyright © 2004-2017    Keith Parkansky    All rights reserved.
"Bestdam Logger" and the BDL graphic logo are trademarks of Keith Parkansky.
Certain graphics, symbols, and terms used on this site and in its documents are registered trademarks
of their respective owners and are contained herein for identification purposes only.
No endorsement of this site, its contents, or its documents by these owners is expressed or implied.

LIABILITY
IN NO EVENT WILL KEITH PARKANSKY BE LIABLE TO ANY PARTY (i) FOR ANY DIRECT, INDIRECT, SPECIAL, PUNITIVE OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, DAMAGES FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, LOSS OF PROGRAMS OR INFORMATION, AND THE LIKE), OR ANY OTHER DAMAGES ARISING IN ANY WAY OUT OF THE AVAILABILITY, USE, RELIANCE ON, OR INABILITY TO USE THE INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED OR TRANSMITTED FILES OR GENERATED COMMUNICATIONS OR DATA EVEN IF KEITH PARKANSKY SHALL HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES, AND REGARDLESS OF THE FORM OF ACTION, WHETHER IN CONTRACT, TORT, OR OTHERWISE; OR (ii) FOR ANY CLAIM ATTRIBUTABLE TO ERRORS, OMISSIONS, OR OTHER INACCURACIES IN, OR DESTRUCTIVE PROPERTIES OF ANY INFORMATION, METHODS, HTML OR COMPUTER CODE, OR "KNOWLEDGE" PROVIDED ON OR THROUGH THIS WEBSITE OR ANY OF ITS' ASSOCIATED DOCUMENTS, DIAGRAMS, IMAGES, REPRODUCTIONS, COMPUTER EXECUTED CODE, OR ELECTRONICALLY STORED, TRANSMITTED, OR GENERATED FILES, COMMUNICATIONS, OR DATA. USE OF THIS SITE CONSTITUTES ACCEPTANCE OF ALL STATED TERMS AND CONDITIONS.