Can't sue fcgi, and have to wait a long time for sites to show up after creating.

OK In the earlier post, I was having problems with the web sites coming up. Well they all come up now, but in order to do it, I had to disable fcgi, and just go with standard cgi. It all works, but from what I read the php scripts run faster with fcgi.

Now Same server, same software for the sites, I even had php5.2 the last time when everything was running just fine. This time it was me that did a stupid thing. We won't go into that. The point is everything ran just fine before my brain fart. The only thing that is different is I installed CentOS 5.8 64bit, when before the crash I had installed CentOS 5.5, and it had automatically upgraded to CentOS 5.8.

Point is it all still should work with fcgi enabled. But it don't, and I can't for the life of me figure out why. So I really need someone to log in and let me know what I need to fix to get it back to using fcgi.

One other thing that has me puzzled is if I create a Virtual Server, it takes it about 2 hours for the site to show up on the web. I can ftp to it, no problem, I can access the database from with-in Virtualmin, but I can't go to the url for about 2 hours, and it has never been that way before. before when I create the server, I can ftp to it, and upload the site, and I can surf right to it, no wait. Also My Mail server starts right away. So it is working right.

I have my own DNS Server, and because I access all my sites it must be working right. Is there a setting for time to live or something like that?

Thanks

Michael

Status: 
Closed (fixed)

Comments

We can take a look to make sure FCGID is working properly.

What I can do is setup a test PHP application to make sure it runs under FCGID. If it does, that may suggest a configuration issue with the particular PHP applications that you're using, and that's something we wouldn't be able to fix. However, we can certainly make sure that FCGID is working properly, and that we don't see any configuration issues that prevent FCGID from working.

That said, a lot of folks (including myself) do use CGI on their servers. Not everyone finds the speed difference to be significant for the sort of traffic they're doing (ie, it may only be noticeable under higher loads), and using CGI removes a layer of things that can go wrong.

But I'll gladly take a peek and let you know if I see anything awry.

I would love to have you take a look here, I don't know what to do, I have a X-Cart Store (PHP site) and at the moment the Store is closed. If you try to access it "www.asr-systems.com" you get this error. The requested URL /cgi-bin/php5.fcgi/shop_closed.html was not found on this server. it should pop up the "Stores Closed.html" the page is there.

Now I thought I had fcgi disabled in "Server Configuration/Website Options" where I set PHP script execution mode Apache mod_php (run as Apache's user) But I guess not. That was the only one that allowed the sites to come up. I have no idea what to do here, I have Googled this for 2 days now, and have not found an answer.

Also I know the DNS Server is working, but if I create a Virtual Server, it takes about 2 hours for it to show up on the web, and that has never been that way before. I always showed up immediately, so I don't know whats going on there. Is there a setting "Time to Live" or something like that?

I have 3 PHP sites, and I had to disable fcgi on all 3 to get the sites to work. If I have to switch to CGI, I can live with it, but all 3 sites were working just fine before I messed up the server and had to reinstall CentOS 5.8

Anyway if you could take a look, it would be most appreciated. Just send me your e-mail address, as my login info has changed.

Thanks Regards Michael

The requested URL /cgi-bin/php5.fcgi/shop_closed.html was not found on this server

That sounds like a PHP configuration problem -- not all web applications are compatible with all PHP versions, it sometimes requires tweaking the PHP parameters.

It's possible that you had a slightly different PHP version in the past (even different versions of PHP 5.2 can cause that). It's also possible that your php.ini file was in some way changed from when things worked in the past.

That particular error can typically be resolve by editing $HOME/etc/php.ini, and setting "cgi.fix_pathinfo" to "0".

Once you do that, you may have to clear your browser cache before it begins working, as your browser may have cached the incorrect links.

If you'd like me to login and take a peek, I can, you can email me at eric@virtualmin.com -- but my suggestion would be to try tweaking your php.ini file first, as that's where I'm going to start :-)

Your PHP/FCGI setup appears to be working well.

It looks like there was a problem with the line that was added to the php.ini file, that should look like this:

cgi.fix_pathinfo = 0

However, that may not have been the issue... the issue appears to be due to an .htaccess file that's setup in your public_html folder. It had these two lines in it:

AddHandler php5-fastcgi .html
Action php5-fastcgi /cgi-bin/php5.fcgi

Your "We're closed" page didn't begin working until I commented those lines out.

Also, I setup a test PHP script here:

http://www.asr-systems.com/test.php

And all that looks good.

So PHP on your system appears to be working well.

I see that it's working just under mod_php though, rather than fcgid or cgi -- I'm looking into that further.

FCGID tends to hide errors pretty well. But when running under CGI, your logs are showing this error:

suexec policy violation: see suexec log for more details

That led me to look at your Apache config. It looks like the user/group that suexec is setup to switch to when using CGI/FCGID is incorrect.

How did you go about migrating to your new server? Did you just import the Virtualmin backups? Or did you by chance copy the Apache config file as well?

However, I fixed the entries in your Apache config (the SuexecUserGroup lines), and I see that your asr-systems.com site is able to run using all 3 PHP Execution Modes.

I had Virtualmin do backups every night before the crash, but it was set to just do incremental backups, so basically, I started from scratch. I had CentOS repartition the main drive, and left the backup drive alone. It then Formatted the drive, and installed CentOS, I just had it do a basic install. Then I installed Virtualmin. After that I created the base site on IP 202 (asrservice.com) Then ftped the web site to that server. I then created the 2nd Virtual Server on IP203. I then Ftp'ed to the new server and uploaded a complete backup of the site that I had on another backup drive. and then used the backup that Virtualmin made to restore the database and everything else. I thought that would put the site back the way it was. Guess I was wrong. I did that with the other 3 sites.

The 2 lines in the .htaccess file were put there by me, I Googled the fcgi error message I was getting, and found a site were other people were having the same problem on there CentOS system and they said that they added those 2 line to the .htaccess file, and the problem went away. It didn't do anything for my system. I just forgot to remove them.

It looks like there all working now with fcgi enables, so I guess you fixed it. I have to hand it to you guys, you really know your way around Linux. I will try to keep my fingers out of thing that I shouldn't be messing with. But I'm really trying to learn how to do all this by my self. Problem is I'm old, and my mind doesn't work as well as it use to, so I forget thing on a regular basis. I think the Cancer, Radiation, and Chemotherapy didn't help much.

Mark it as fixed. Thank you.

Best Regards Michael

We're happy to help, I'm just a little puzzled as to how that problem might have happened.

Are all of the sites from your old setup on here now?

However, I'm glad it's working now!

Are all of the sites from your old setup on here now?

Ya all but one, just not sure I will put it back up, after all it was just a site in progress.

We're happy to help, I'm just a little puzzled as to how that problem might have happened.

Like I said, The install took forever, about 2 hr just to install CentOS, and about 1 and half hr. to install Virtualmin. And there were errors. When I installed CentOS 5.5 it only to just under 1 hr to get it and Virtualmin installed and ready to use. So something in the install was not working right.

That's why I thought about going back to CentOS 5.5, I didn't have any of these problems. I did have problems with set up, but it was just that I didn't know how to do it. I had a lot of problems with the install with CentOS 6.2 also, that's why I went to CentOS 5.8.

Any way Thank you for finding the problem.

Best Regard Michael

Like I said, The install took forever, about 2 hr just to install CentOS, and about 1 and half hr. to install Virtualmin. And there were errors. When I installed CentOS 5.5 it only to just under 1 hr to get it and Virtualmin installed and ready to use. So something in the install was not working right.

That's why I thought about going back to CentOS 5.5, I didn't have any of these problems. I did have problems with set up, but it was just that I didn't know how to do it. I had a lot of problems with the install with CentOS 6.2 also, that's why I went to CentOS 5.8.

Well, the time it took to install shouldn't be the issue here... even if something went awry during the installation, it shouldn't have caused the issue I tweaked.

In theory :-)

We'll keep an eye out for other issues like that though, and if we can pinpoint what causes that, we'll find a way to prevent it from happening.

I wouldn't suggest using CentOS 5.5, since that release is two years old. The only way to get security updates is by using the newest version of CentOS 5 (which is what you have there now, CentOS 5.8).

You might end up with even more problems if you were two use a two year old distribution with no security updates :-)

I'm glad things are working now though, I'll mark this as fixed!

Thank you, and I don't plan on going back to 5.5, its all working now, so I'm not going to touch it.

Michael

Automatically closed -- issue fixed for 2 weeks with no activity.