Interpreting PHP error_log statements

Here are three versions of the same error message (PHP 5.x and Red Hat Linux OS):
(1) [Fri Jan 30 12:06:57 2015] [error] [client] File does not exist: /var/www/vhosts/
(2) [Fri Jan 30 12:07:28 2015] [error] [client] File does not exist: /var/www/vhosts/
(3) [Fri Jan 30 12:38:32 2015] [error] [client] File does not exist: /var/www/vhosts/

Statement #1 is most perplexing. The file login.php (I get the same message if I use login.php) calls itself. In older programming languages it would be called a recursion. Yet the server can’t find the self-same file whose code it is executing. I’ve tried using a complete URL for the file call -i.e., http:/MyDomain/folder-containing-login.php/login.php, and that doesn’t solve the problem.

Statement #2: What’s Linux address …/var got to do with this?

Statement #3: Nowhere in this ecommerce application is there a “zencart” file. The database is named zencart-database. Would it be not unprecedented that the error log generator would clip the characters zencart from the complete database name?

So there it is. My complete perplexity. Any wisdom regarding this issue would be greatly appreciated.

Never used Linux myself but that file location looks a little odd, especially this part:

Check the include path(s), maybe you’re trying to include from the wrong folder

The addresses you are getting there are the actual location on the server rather than web addresses.

The first thing we need to know to be able to make sense of it is which of the directories in that structure is the one that the domain points to.

We would also need to know if you have any redirects set up (in the .htaccess file or elsewhere) that would affect where the system looks for files.

Also what does the code look like where you are making the call?

Thanks for your prompt response to my post. The addresses have to be “actual” server locations because that’s where the application resides. This zencart ecommerce site works perfectly -calls correctly find files on the server- except for this one administration file which enables content to be placed on the site.

DNS points to (my anonymous name used for this post).

There are no redirects.

I’ve been unable to pin-point with certainty the precise line of code making the call to the unlocatable file because I can’t get a file-open-with-write-privileges to function so that I can perform a trace. However, I have reason to believe that it is the following code line which makes the call:

“form id=“loginForm” name=“loginForm” width:500px; height:500px; action=”<?php echo zen_href_link(FILENAME_LOGIN, zen_get_all_get_params(), 'SSL');?>" method=“post” onsubmit=“animateRHR(this)”

I’ve removed the HTML tags to get this line of code to stay in this reply. If it vanishes after I “reply” I’ll try another strategy.

FILENAME_LOGIN is a global string variable set to “login” in a file of “define” statements.

Following is the animateRHR() function:

function animateRHR(f)
var button = document.getElementById(“btn_submit”);
var img = document.getElementById(“actionImg”);“wait”;
button.disabled = true;
button.className = ‘hiddenField’;
img.className = ‘’;
return true;

“true” is the default value for “button.disabled =”. Changing the value to “false” doesn’t resolve any difficulty.

There’s a catch-22 for my attempt to debug the code. It’s precisely this administration utility that would enable me to find the location of the function: zen_get_all_get_params().

So those are the facts available. The issue of not getting a file to open and be written to is an independent issue I may post separately.

Is that an IP you recognize? Or is this a bot scanning for potential weaknesses in your site? If it’s a bot, seemingly random 404’s would be it trying to find common URL weak points to attack.

StarLion, thank you for your prompt response. It’s my ip. Had it forever.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.