BigNoseBird.Com- Small Logo
The 508 compliant Guide to 
       Big Nose Bird
Site Search Engine

The surfer-bone is connected to the ISP-bone.
The ISP-bone is connected to the switch-bone.
The switch-bone is connected to the nap-bone.
And that's just part of it.

The nap-bone is connected to the back-bone.
The back-bone is connected to another nap-bone.
The nap-bone is connected to the host-bone.
And we are almost there.

The host-bone is connected to the router-bone.
The router-bone is connect to the server-bone.
The server-bone is connected to the web-bone.
And that is how we surf the 'net!

Your website is your reader's destination. Getting from Point A to Point B is not as simple as it may appear. All sorts of things can go wrong along the way. This page contains information about what you can do to get an idea of where a problem might be before calling anyone for help. So whether you have a problem getting to your site or you have a script that stopped working, you may be able to find your answers with the methods explained here.

Why won't my site respond? Is it dead or just comatose?
No matter what precautions we take, our sites will every now and then fall under the weather. There are many reasons for web malaise, including:
  • Your connection to the internet. It is quite possible you have a problem with your ISP and your access is slow. Try visiting other sites and see how the response time is.

  • The whole internet or parts of it are slow. During peak hours, many backbone providers and local servers get bogged down with e-mail requests, etc...

  • Problems with your server. It is possible that there is in fact a problem at your end. It can be anything from a communication routing problem to an overloaded server.

  • Maybe you are the Yahoo! Pick of the Day. Yeah, and that is Ed McMahon ringing your doorbell!
Quite often, by the time you figure out the problem, it will have somehow fixed itself. Somehow your site knows a trip to the doctor might happen and all of a sudden, everything stops hurting.

Is there anything I should do before calling the Doctor?
There are some diagnostics you can perform to get an idea of what the problem might be. Before calling for help, having a good idea of where the problem might be can save you some time and embarrasment. Believe me, our former hosting company hated/loved us. If you are using Windows 95/NT, start up a DOS window and try the following:
     *TIP! ping your site at different times of the day and
              night so you can get an idea of your site's 

        Exit your browser, FTP, and e-mail program.


        The computer will respond with the following 

        Pinging [BIGNOSEBIRD.COM] with 32 bytes of 
        Reply from BIGNOSEBIRD.COM: bytes=32 time=170ms TTL=245
        Reply from BIGNOSEBIRD.COM: bytes=32 time=171ms TTL=245
        Reply from BIGNOSEBIRD.COM: bytes=32 time=180ms TTL=245
        Reply from BIGNOSEBIRD.COM: bytes=32 time=181ms TTL=245

        This example indicates a nice, healthy, responsive site.
        Notice that the time for the response from the server is
        under 200ms, or 1/5 of a second.

        An unhealty connection might look like this:

        Pinging [BIGNOSEBIRD.COM] with 32 bytes of 
        Reply from BIGNOSEBIRD.COM: bytes=32 time=780ms TTL=245    
        Request timed out
        Reply from BIGNOSEBIRD.COM: bytes=32 time=810ms TTL=245    
        Request timed out

        If you get no response back from the command, well the
        problem is very serious!

What other tests can I run?
Let's consider the PING command as being the oral thermometer. If the site is not reachable or the response times are very long, we must resort to that other kind of measurement tool. In this case, it is the tracert command. This little program when run from the DOS window, shows us the journey from your PC to your site. The path you take might surprise you!

What is meaningful about this test, is that we can see how long the various hops from point to point take.

   Exit your browser, FTP, and e-mail program.


Tracing route to [BIGNOSEBIRD.COM]
over a maximum of 30 hops:
  1   160 ms   130 ms   140 ms [] 
  2   140 ms   140 ms   130 ms [] 
  3   140 ms   140 ms   140 ms [] 
  4   160 ms   220 ms   221 ms [] 
  5   160 ms   151 ms   150 ms [] 
  6   141 ms   150 ms   150 ms [] 
  7   150 ms   150 ms   150 ms [] 
  8   150 ms   160 ms   140 ms [] 
  9   160 ms   150 ms   161 ms [] 
 10   180 ms   171 ms   150 ms [] 
 11   181 ms   180 ms   180 ms [BIGNOSEBIRD.COM] 
Trace complete.
The example above looks pretty healthy, but it still is amazing how many systems every character must pass through to get to and from our server.

Tracing route to []
over a maximum of 30 hops:
  1   150 ms   130 ms   141 ms [] 
  2   140 ms   141 ms   130 ms [] 
  3   150 ms   141 ms   140 ms [] 
  4   171 ms   140 ms   150 ms [] 
  5   160 ms   140 ms   180 ms [] 
  6   160 ms     *      151 ms [] 
  7   220 ms   231 ms   240 ms [] 
  8   231 ms   230 ms   230 ms [] 
  9   220 ms   220 ms   241 ms [] 
 10   221 ms   230 ms   220 ms [] 
 11   240 ms   270 ms   231 ms [] 
 12   250 ms   231 ms   220 ms [] 
 13   241 ms   240 ms   251 ms [] 
 14   250 ms   251 ms   240 ms [] 
 15   350 ms   321 ms   320 ms  ATM1-0-7.balt01.xxxxxxx.NET [] 
 16   341 ms   370 ms   341 ms [] 
 17   381 ms     *      371 ms  333.33.3.33 
 18     *      511 ms   431 ms  444.444.44.444 
Trace complete.
In the example above, we have changed the names and IP addresses to protect the innocent, but it is real. Reading down all 18 hops, we can see that things look pretty good until we hit our first minor snag at #6, but things are still in the 200 range. Once we finally get back to the east coast (baltimore), we notice a 350ms average time around the hosting companies connection to the backbone. The final coup de grace is getting into the hosting company and then finally to the server the site is located on. This situation would merit a call to the hosting company.

Do not call yet! Wait a little while. The problem might be temporary or actually at the backbone provider. Wait an hour or so to see if the problem clears up.

There is another interesting problem here that we might want to ask the local ISP about. To get from Long Island, NY to Baltimore, Maryland my route to the server is about 6,000 miles. If I were to get in my car and drive to this server, it would only be about 250 miles!
However, if the long times are located between you and your service provider, then don't bug the hosting company. If the delay is someplace in the middle, then only an entity that has no name and answers only to a greater power can help. In otherwords, it's a bottleneck on the Internet itself and you are stuck.

A much more serious problem would look like this:

 15   350 ms   321 ms   320 ms  ATM1-0-7.balt01.xxxxxxx.NET []
 16   341 ms   370 ms   341 ms []   
 17   381 ms     *      371 ms  333.33.3.33
 18     *        *        *     444.444.44.444
 19     *        *        *     444.444.44.444
 20     *        *        *     444.444.44.444
Desination reported unreachable
This means your site is down and off-line for some reason. Again, there are many causes of this problem and we suggest waiting a little while before calling. When we experience problems, we usually send a cute e-mail to the support department. We usually never call on the phone because the last thing I want to do is pull the technician away from a problem he or she most likely already knows about.

Why would a script suddenly stop working?
There are several reasons why a reliable and trusted script would suddenly cease functioning, including:
  • Your site has been moved to another server where the directory names, or the path to your site has changed. One day you are on /home/u/myweb and the next day you are in /h10/u1/myweb. The script is still being called properly, but if it has any hard coded paths in it, then the script will fail.

  • The script was consuming too many system resources and the system administrator disabled it. If you look at the file's permissions and they look like -rw-r--r-- then this may be the problem. If you are positive that you did not do this, write to your system administrator and ask if there was a problem.

  • New server software. On occasion, the companies that make the software that runs our sites will issue updates. It is possible that a function you need is no longer supported. If this happens, you will not be alone and your host should be able to supply you with some information on what to do. If you know the name of your server, such as APACHE, and the version number, you can go to their site and research the issue on your own.

  • Changes in server configuration. Related to the above, hosts can tune their server software to include or exclude certain features. This is especially true with security problems. A great example of this has to do with many hosts not allowing the Server Side Include EXEC. The way around this problem is to use the VIRTUAL include. Again, when changes like this happen, your administrator should notify you in advance so you can take care of it before it becomes a problem.

  • Self inflicted wounds. This is probably the main cause of such problems. We are guilty of it as much as anyone else. It's late at night, in a rush, not enough coffee, and we make that little tweak to a script and then not test it. The next day, the script is not working and we do not remember why. Always test your scripts after any change!

What can I do to fix a broken script?
The most important thing you can do when faced with a script failure problem is take about ten deep breaths before dealing with it. Then, follow these simple steps to trace the cause of the problem.
  • Check your E-mail. Go read your mail. Maybe there is a note from your system administrator notifying you that something has been changed on the system that might affect your site. If this is the case, then the letter probably holds the answer. If the letter does not make sense to you, the reply to the letter and ask for clarification.

  • Check the script's modification date. Look at the directory listing for the script. If the date seems more recent than the last time you remember working on it, then either you or somebody else modified it. If you have a back-up copy of the script, compare the two and look for differences. This also applies to any related configuration files.

  • Check the script's permissions. If you notice that the execute permission on the file has been removed, then you need to figure out if you or the system administrator did it. Often when the sysadmin does this, they also change the ownership of the script so you can't change the permissions back! As I mentioned in the last section, if this is the case, write your sysadmin for advice.

  • Check your website's physical path. Whether using FTP or telnet, issue the pwd command to find out the full path to the directory where your script resides. If it looks no longer agrees with what paths are in your script(s), edit your scripts with the new path. If you were not notified, write your sysadmin a polite letter thanking them for not notifying you of a change that affected the operation of your site. Of course, if you find an e-mail from three days ago notifying you of an upcoming change....

  • Check file sizes. If your script creates a log file or other type of output file, check to see how big it is. Many sites have what is called a ulimit. Your sysadmin can advise you on this if you do not have telnet access. If you can log into your site via telnet then issue the ulimit command at the prompt. The result should be either unlimited or a number. The number is how many blocks large a file can be. You will need to then find out whether a block is 512 or 1024 bytes on your server and multiply the ulimit result by the block size to figure out the maximum file size. Fun?
If you have checked everything out and all seems okay at your end, the write your sysadmin. There is a chance that some minor system change was made that they did not think would affect anything. The odds are pretty good that the checklist above will resolve most problems.

You might consider placing a copy of BIRDSEYE.CGI on your server. This free script allows you to run diagnostics right from your server using browser.

Find or Give Help on the BBS
Home Top E-Mail
If it looks great, it's by Christine
Some Fine Print
© 1997-2003 BigNoseBird.Com®, Inc. All rights reserved. All other trademarks are the sole property of their respective owners. The products that we recommend are only ones that we use. We have no relationship with any of the authors or their companies. We cannot assume responsibility for their ultimate performance or lack of same. We also cannot assume responsibility for either any programs provided here, or for any advice that is given since we have no control over what happens after our code or words leave this site. Always use prudent judgment in implementing any program- and always make a backup first! For further information, please read our Privacy Statement. We can be contacted at

Web Builder Network Portal
on the
BigNoseBird Newsletter

Sign up today to receive our low volume newsletter. Tips, tricks, news, and whatever else crosses our minds.
Back Issues
Privacy Statement