Hello and welcome to our community! Is this your first visit?
Register
Enjoy an ad free experience by logging in. Not a member yet? Register.
Results 1 to 2 of 2
  1. #1
    New to the CF scene
    Join Date
    Oct 2010
    Posts
    7
    Thanks
    0
    Thanked 0 Times in 0 Posts

    Persistent Error 500 from Server Side CGI Script Caching??

    I've run into an issue where once in a while a CGI script (PERL) starts throwing an Internal Server Error 500.

    I verified the script owner user, group and permissions are correct (domain user, psacln, 755)

    I couldn't see any problem with the script so I went in and edited the offending script so that all that is in it is a print statement:

    #!/usr/bin/perl
    print "Content-type: text/html\n\nHELLO<BR>";

    No matter what we name the script it still generates an error 500 while other scripts in the directory are running fine.

    We tried running the script for a different browser thinking maybe the browser was caching the page but it also generated the error.

    Then we simply stopped and started Apache and it worked fine with NO changes to the script. The script WAS re-saved though as in the past, I've found sometimes my CuteFTP (for whatever reason) saves a script file and uses BINARY when it should use ASCII (or vice versa) and I have to go into the shell and PICO edit the script and just re-save it with no changes. But I did this also in this case before restarting Apache and it didn't fix the error.

    This makes it appear as if Apache is caching script execution on the server side but I fail to see how/why it would do that when we are modifying the script!

    Again we are using PERL CGI (not mod_PERL) on Plesk 10.1.1. Anyone run into this or have an ideas what would cause it to happen?
    Last edited by consultant1027; 03-29-2011 at 11:44 PM.

  • #2
    Master Coder
    Join Date
    Dec 2007
    Posts
    6,682
    Thanks
    436
    Thanked 890 Times in 879 Posts
    Quote Originally Posted by consultant1027 View Post
    I've run into an issue where once in a while a CGI script (PERL) starts throwing an Internal Server Error 500.

    I verified the script owner user, group and permissions are correct (domain user, psacln, 755)

    I couldn't see any problem with the script so I went in and edited the offending script so that all that is in it is a print statement:

    #!/usr/bin/perl
    print "Content-type: text/html\n\nHELLO<BR>";

    No matter what we name the script it still generates an error 500 while other scripts in the directory are running fine.

    We tried running the script for a different browser thinking maybe the browser was caching the page but it also generated the error.

    Then we simply stopped and started Apache and it worked fine with NO changes to the script. The script WAS re-saved though as in the past, I've found sometimes my CuteFTP (for whatever reason) saves a script file and uses BINARY when it should use ASCII (or vice versa) and I have to go into the shell and PICO edit the script and just re-save it with no changes. But I did this also in this case before restarting Apache and it didn't fix the error.

    This makes it appear as if Apache is caching script execution on the server side but I fail to see how/why it would do that when we are modifying the script!

    Again we are using PERL CGI (not mod_PERL) on Plesk 10.1.1. Anyone run into this or have an ideas what would cause it to happen?
    hard to say, fastcgi could do this sometimes but apache also have some problems. Did you stop - start apache or reload/restart ?
    try to stop and after a while start
    also try to clear browser cache, or change the browser with something less 'smart' like dog, curl or lwp.
    check if you don't have a proxy somewhere between you and the site.

    Edit: i forget what must be first thing, what do you find in server error logs and access logs?


    best regards


  •  

    Posting Permissions

    • You may not post new threads
    • You may not post replies
    • You may not post attachments
    • You may not edit your posts
    •