The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Perl modules and problem users scripts

Discussion in 'General Discussion' started by ozzi4648, Nov 25, 2002.

  1. ozzi4648

    ozzi4648 Guest

    Around 2 weeks ago, we had a reseller transfer over to our cPanel server from another service he said was to slow for him. He was concerned that we had certain Perl modules installed including Imagemagic. We did and he was happy. The first site he setup, as reseller, was selling webhosting. The second was an auction site, perl scripts, that he had purchased for about 300.00 that he setup under an auction site name.

    After he setup his mysql database we received numerous errors where his perl scripts could not connect to the mysql database. I ensured him that DBI:Mysql was installed, according to list of perl modules it was, but he kept telling us it wasn't. This went on for a few days till i got sick of it and re installed the perl module from WHM. After we reinstalled DBI:Mysql he was able to connect to Mysql. WEIRD! Why did i have to do that you ask? Beats me. WHM said it was installed so why didnt it work?

    Over the course of a week numerous errors were appearing in our error_log files. I told him to fix his scripts but he kept telling me that he has been using these scripts for 2 years and never saw these errors before on any server. I told it was probably because nobody ever checked the log files on his site. Here are some of them.

    DBD::mysql::st fetchrow_array failed: fetch() without execute() at
    includes/close_item.pl line 52.
    [Thu Nov 21 10:38:28 2002] [error] [client 66.201.156.164] File does not
    exist: /usr/local/apache/htdocs/auctionimages/regi$
    [Thu Nov 21 10:38:28 2002] [error] [client 66.201.156.164] File does not
    exist: /usr/local/apache/htdocs/404.shtml
    DBD::mysql::st fetchrow_array failed: fetch() without execute() at
    includes/close_item.pl line 52.
    DBD::mysql::st fetchrow_array failed: fetch() without execute() at
    includes/close_item.pl line 52

    So we spent countless hours emailing back and forth and i finally told him it was his scripts and that he had to fix them. My error log was growing and i was getting tired of the whole thing.

    I got onto our second cPanel server and did a site copy. I copied his entire site over to a fresh cPanel server. I wanted to see if the same errors happen there also. Sure enough, the same errors keep coming up over and over and over, even on a bran new cPanel server. Now his threatening to leave. Im not so worried about that, but that makes me really think about the perl modules installed on cPanel. Whats up with those? Is it his script or is it our server.

    He keeps telling me that his scripts never errored out on any other server which i find hard to believe. Unless the owner of the server actually monitored the error log nobody would have even caught that fact that his scripts were sloppy.

    My question is. Does anyone know if Perl modules have to be copied into the virtual site? How are Perl modules accessed from a virtual site? On Ensim you have to copy them into the VS. This still puzzles me so i was wondering if anyone knew.

    -Thanks
     
  2. dgbaker

    dgbaker Well-Known Member
    PartnerNOC

    Joined:
    Sep 20, 2002
    Messages:
    2,578
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Toronto, Ontario Canada
    cPanel Access Level:
    DataCenter Provider
    From what I can see it is his scripts.
    Example;
    File does not
    exist: /usr/local/apache/htdocs/auctionimages/regi$

    Somewhere his scripts are looking for files in the wrong area.

    You could on the mirrored copy search for this path to prove the point. In his scripts the absolute paths should be to /home/user/public_html etc....
     
  3. ozzi4648

    ozzi4648 Guest

    Aside from the not found files. Howabout the DBD:Mysql? The scripts dont actually fail but what im saying is we get these errors. I also think its the way his initially connecting to the database and then disconnecting from it. How do you convince somebody that their scripts are just not coded up to standards? Here is what he says:

    Michael, can you dump the latest error log into my home directory again? I have four other associates of mine with auction sites using this same software, and their SP's say there is no problem with their scripts, so I can only assume that either there is an irresolvable issue and I need to go elsewhere or something is not right on the server and it just has not been discovered. I am going to look one last time at these current errors and
    see if I can't figure out the problem. I am part of a community that develops UA now, but nobody else is having these problems so they have backed out of having the scripts re-written. If I have a problem, it will be up to me to fix it. Too expensive to go alone. One last look at the error logs may help me figure out what the problem is.

    I apologize for the hassles, but I assure you I have used these scripts for over two years and never had issues like this, so it has taken us all by surprise. Now that nobody else can see these issues on their sites, I am alone in this endeavor. I may have no choice but to find another SP, but I have to see if this is a Perl incompatibility problem or something else before I go and run off to someone else. Just work with me the best you can and we will do our best to fix what we can as fast as we can.
     
  4. dgbaker

    dgbaker Well-Known Member
    PartnerNOC

    Joined:
    Sep 20, 2002
    Messages:
    2,578
    Likes Received:
    3
    Trophy Points:
    38
    Location:
    Toronto, Ontario Canada
    cPanel Access Level:
    DataCenter Provider
    ozzi;

    One point he makes, perl incompatibility, since the scripts are older ones is it possible that the others that say &no issue& are using an older version of perl?.

    As for how to tell someone there code sucks? Next to impossible as developers never make bad code, only sysadmins run bad systems.

    P.S. That was a quote thrown at me at one time by a Vignette developer. As he put it &My programs aren't working, my code is perfect, now fix the system.
     
  5. ozzi4648

    ozzi4648 Guest

    [quote:70086d896c][i:70086d896c]Originally posted by dgbaker[/i:70086d896c]

    ozzi;

    One point he makes, perl incompatibility, since the scripts are older ones is it possible that the others that say &no issue& are using an older version of perl?.

    As for how to tell someone there code sucks? Next to impossible as developers never make bad code, only sysadmins run bad systems.

    P.S. That was a quote thrown at me at one time by a Vignette developer. As he put it &My programs aren't working, my code is perfect, now fix the system.

    [/quote:70086d896c]

    NOD, thats what i told the guy in one of my e-mails. He was running these scripts on an Ensim server which runs Perl 5.6.0. Never had a problem he says. Now his running it on Perl 5.6.1 cPanel. Incompatible, but as a developer on other platforms i would have thought that Perl 5.6.1 was BACKWARD compatible? So it should take into account their older style of programming.
     
Loading...

Share This Page