Perl modules and problem users scripts

[ozzi4648]

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

 

[dgbaker]

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....

 

[ozzi4648]

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.

 

[dgbaker]

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.

 

[ozzi4648]

[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.