![]() |
||
![]() |
1.0.4 Documentation | ![]() |
![]() |
![]() |
7. Troubleshooting7.1 How to Troubleshoot7.1.1 Questions to Ask7.1.2 Places to Look for Diagnostics and Clues7.1.2.1 Error LogsOften, webserver problems can be ferreted out by examining the error logs that are generated by the server. As an example, Apache's error logs can usually be found in /usr/local/apache/logs. Within this directory are logs for the webserver itself; these usually list errors in starting the server or in its configuration. Also found there are logs specific to each host (virtual if more than one) that your webserver handles. These are usually more informative for finding AllCommerce installation or configuration errors. 7.1.3 Where to Get HelpYou can join the mailing lists at http://lists.zelerate.org/mailman/listinfo. The devel (development) and docs (documentation) lists are best for asking questions. You can post a problem or question and it will usually be answered by another user or by a member of the development or documentation teams. 7.2 Zelerate AllCommerce Script Diagnostics7.3 Operating System Problems7.4 Database ProblemsMost database problems (post installation) have to do with improper configuration of the values in database.conf. Such errors can usually be discovered by examining the server logs for your site. The most common errors involve a bad name given for the site_server, but all of the database.conf values are equally important to allow AllCommerce scripts to successfully interact with your database. 7.5 Webserver ProblemsCheck those error logs! Also, sometimes people have more than one httpd.conf file on their computer. This could happen if Apache was already installed, unknown to the user who installs it again (e.g., via a download from www.apache.org. If you are certain you have all the values set and everything configured correctly, but you are still getting odd "denial of access" errors when you point your browser to your newly installed store, try doing a locate for httpd.conf: locate httpd.conf If you get a list with more than one instance of the file, possibly in /etc/httpd/conf and /usr/local/apache/conf, then you need to find out which one your webserver is reading when it starts up. One way to do this is to stop your webserver, change the name of both httpd.conf files, then restart Apache and see which file it tries to read (It should fail to start and complain about not finding httpd.conf. If this happens, and the one it wants to read was not the one you set up, well, you know what to do. Be sure that the host and domain values set in site.pm match what is listed in /etc/hosts and your VirtualHost declaration in httpd.conf. If you used www.presents.com as an example for the sample store installation, then site_domain should be ".presents.com" and site_server should be "www". Make sure that your VirtualHost declaration has www.presents.com in the beginning of the declaration: Also make sure that ServerName is also www.presents.com within your VirtualHost declaration. For /etc/hosts, if you are just testing on a local installation, you need to put "www.presents.com" on the same line as your localhost.localdomain name. For example: 127.0.0.1 localhost.localdomain www.presents.com This may seem trivial, but it seems to happen often and can be the cause of much frustration and wasted time. When restarting your webserver after modifying httpd.conf, it's best to do a: killall httpd.conf to be sure all the little daemons really did stop. Next do a: pstree to be certain they're all in heaven, before restarting the server. Simply doing "apachectl restart" may not really stop them all. It appears that sometimes you can start a new server while the old ones are still running! Then, depending on which one gets your browsers' request, things may or may not work. 7.6 Payment Processor ProblemsIf you encounter the payment processor problem related to Credit Card Verification System (CCVS), you can look at the section on os_allcommerce and (CCVS). |