I am trying to add an extension to my PHP. I have the file - libssh2.dll - in the appropriate directory (as listed in my php.ini file) and made sure the extension=libssh2.dll. I also copied the .dll file to system and system32 folders as other threads have suggested. When I try to start my Apache server I get the following windows error:
Apache HTTP Server has encountered a problem and needs to close. We are sorry for the inconvenience.
and Apache Monitor error:
The requested operation has failed!
I check the log to see this:
[Tue Jul 26 16:43:06 2011] [warn] pid file C:/Program Files/Apache/logs/httpd.pid overwritten -- Unclean shutdown of previous Apache run?
I have tried to go in this direction but am completely stumped at this point. Hoping someone out there can help me and so I can figure out what's wrong. Thanks in advance guys!
Cheers
I think that it is telling you that you need to remove just the previous pid file. Each time that you run apache a http.pid file is created in apache's bin folder. It contains the apache pid.
I solved it by upgrading to 5.3. Somehow with the same settings it automagically worked. Closing the issue now.
Related
I've installed php, mysql, apache with WAMP for windows 10. When I go to http://localhost there is not any problem, the appropriate page is shown. The server is up and running, but when I try to open http://localhost/test.php it gives me 404 not found error. By the way I've put the index.html and test.php into wamp64/bin/apache/apache2.4.46/htdocs. The server can access neither index.html in that directory nor test.php. Your help is welcome.
Like #Selim Achour said I looked to the error logs and I found that apache server wasp/ searching the test.php in a folder called wamp/www/test.php. When I move the test.php from htdocs/test.php to www/test.php it works perfectly. I was following instructions from a book that I'd been reading. In that book's instructions, it is clearly stated that you should move test.php into htdocs. That was what got me confused. Thank you all for your effort.
The error: Sat Sep 26 13:14:03.134587 2020] [php7:error] [pid 8220:tid 1204] [client ::1:6466] script 'C:/wamp64/www/test.php' not found or unable to stat
WAMPServer's DocumentRoot folder is C:\wamp64\www BUT You should NEVER place your scripts into that folder!!!
Make a subfolder and use that i.e. C:\wamp\www\test1 put your test.php in there and run using locahost/test1/test.php
Better still create a Virtual Host for all your test areas and development site folders. See THE NEED for VIRTUAL HOSTS and then WAMPServer 3 Create a Virtual Host, the easy way
There are lots of other questions referring to x-sendfile not returning files, but none of them appear to be able to fix my issue.
I am serving images from a directory outside the public root of the site and want to be able to deliver those images to the user with as little overhead as possible, so I want to avoid processing them with readfile(). Hence I am trying to use x-sendfile.
My development environment consists of a XAMPP (apache and php) installation on a 64bit windows. I'm using the 64bit windows binary of mod_xsendfile.so, which appears to be loaded correctly according to phpinfo().
I was thinking it could be a problem around case-sensitivity or backslash/forwardslash but this doesn't seem to be the case.
The file does exist, if I copy the path out of the error log and paste it into an explorer window the image loads. Also I have used file_exists and filesize to verify the path in php.
httpd.conf setup:
LoadModule xsendfile_module modules/mod_xsendfile.so
XSendFile On
XSendFilePath "c:/images-store/"
PHP code
header('Content-Type: image/jpeg');
header('X-Sendfile: c:/image-store/5cca6ef24ae46c4346c24846ee3e5521213562ef-thumb.jpg');
Error log entry
[pid 3208:tid 1900] (20023)The given path was above the root path: [client 127.0.0.1:57477] xsendfile: unable to find file: c:/image-store/5cca6ef24ae46c4346c24846ee3e5521213562ef-thumb.jpg
Any insights as to how I can get these files to be served would be great.
Turns out it was case sensitivity. The c in the path needed to be a capital C.
XSendFilePath C:/images-store/
I should probably switch back to linux for my development...
I am writing a PHP application, and I've just encountered a really wierd error. After a recent move to a new (Ubuntu) server, i started getting fatal errors on a require_once statement. So obviously the file doesn't exist, or the file permissions are wrong, right?
No, as it turns out:
The file does exist
The file is checked out from an SVN repository. When I go into the folder and list the files (ls or ls -l) the file is clearly there and has the correct file size. When I update the file in the repository and update the working copy, the changes are copied to the working copy. The file has permissions 755, so everyone should be able so see and read it. Other files in the same directory are working just fine.
The file also doesn't exist:
PHP exits with a fatal error because the file can't be found. If I use the find-command, the file is not found. If I try to use nano to edit the file, it claims it does not exist. If I start typing the filename and press tab to autocomplete, it can't find the file.
This behaviour has now happened on two separate servers, but it works fine on a third server. All the servers run Ubuntu 10.04.
Does anyone have any idea what is going on?
EDIT:
File name is AdminIpv4RangeAddFormHandler.inc.
Full error message, with file paths obscured:
Warning: require_once(fullpath/AdminIpv4RangeAddFormHandler.inc): failed to open
stream: No such file or directory in fullpath/anotherfile.inc on line 34 Fatal error:
require_once(): Failed opening required 'fullpath/AdminIpv4RangeAddFormHandler.inc'
(include_path='.:/usr/share/php:/usr/share/pear') in fullpath/anotherfile.inc on line
34
The following command produces no output:
find -name AdminIpv4RangeAddFormHandler.inc -ls
A regular ls -li outputs (amongst others) this row:
2233407 -rwxr-xr-x 1 root root 1597 2011-12-13 08:02 AdminIPv4RangeAddFormHandler.inc
Be careful switching OS's, as some are case sensitive, and others aren't.
I use my Mac for development (case insensitive), so it doesn't matter what casing I use for file_exists() or include_once() etc. Then I deployed to Ubuntu 11 (case sensitive), and all my includes stopped working. I suspect you have the same exact problem.
The tricky part for me was, while using git, my version control didn't detect changes in file name case as a modification. I actually had to rename every file with some sort of prefix, commit and deploy, rename them back to what they should be (with consistent capitalization!), and finally commit and deploy again. It was a complete pain.
Moral of the story--code for your production system, not your dev system.
Take a good long look at your filenames:
AdminIpv4RangeAddFormHandler # from PHP
AdminIpv4RangeAddFormHandler # from find command
AdminIPv4RangeAddFormHandler # from ls output
^
You should pick IP or Ip and stick with the decision everywhere.
I am getting the following error from Apache
[Sat Mar 19 23:10:50 2011] [warn] mod_fcgid: stderr: PHP Fatal error: require_once() [function.require]: Failed opening required '/common/configs/config_templates.inc.php' (include_path='.:/usr/share/pear:/usr/share/php') in /home/viapics1/public_html/common/configs/config.inc.php on line 158
I am definately not an expert of Apache but the file config.inc.php & config_templates.inc.php are there. I also tried navigating to a test.html page I placed in common/configs/ so I assume there is no rights issues going on. I also set the rights on config_templates.inc.php to give everyone read, write, and execute rights. Not sure what to do at this point, I checked to see if there was a /usr/share/php directory and I found there was not but when I did yum install php it said it had the latest. Ideas?
It's not actually an Apache related question. Nor even a PHP related one.
To understand this error you have to distinguish a path on the virtual server from a path in the filesystem.
require operator works with files. But a path like this
/common/configs/config_templates.inc.php
only exists on the virtual HTTP server, while there is no such path in the filesystem. The correct filesystem path would be
/home/viapics1/public_html/common/configs/config_templates.inc.php
where
/home/viapics1/public_html
part is called the Document root and it connects the virtual world with the real one. Luckily, web-servers usually have the document root in a configuration variable that they share with PHP. So if you change your code to something like this
require_once $_SERVER['DOCUMENT_ROOT'].'/common/configs/config_templates.inc.php';
it will work from any file placed in any directory!
Update: eventually I wrote an article that explains the difference between relative and absolute paths, in the file system and on the web server, which explains the matter in detail, and contains some practical solutions. Like, such a handy variable doesn't exist when you run your script from a command line. In this case a technique called "a single entry point" is to the rescue. You may refer to the article above for the details as well.
If you have SELinux running, you might have to grant httpd permission to read from /home dir using:
sudo setsebool httpd_read_user_content=1
Run php -f /common/configs/config_templates.inc.php to verify the validity of the PHP syntax in the file.
You could fix it with the PHP constant __DIR__
require_once __DIR__ . '/common/configs/config_templates.inc.php';
It is the directory of the file. If used inside an include, the directory of
the included file is returned. This is equivalent to
dirname __FILE__ . This directory name does not have a trailing slash
unless it is the root directory. 1
Just in case this helps anybody else out there, I stumbled on an obscure case for this error triggering last night. Specifically, I was using the require_once method and specifying only a filename and no path, since the file being required was present in the same directory.
I started to get the 'Failed opening required file' error at one point. After tearing my hair out for a while, I finally noticed a PHP Warning message immediately above the fatal error output, indicating 'failed to open stream: Permission denied', but more importantly, informing me of the path to the file it was trying to open. I then twigged to the fact I had created a copy of the file (with ownership not accessible to Apache) elsewhere that happened to also be in the PHP 'include' search path, and ahead of the folder where I wanted it to be picked up. D'oh!
you can set the include path in php.ini
include_path = ".:/home/viapics1/public_html"
I was having the exact same issue, I triple checked the include paths, I also checked that pear was installed and everything looked OK and I was still getting the errors, after a few hours of going crazy looking at this I realized that in my script had this:
include_once "../Mail.php";
instead of:
include_once ("../Mail.php");
Yup, the stupid parenthesis was missing, but there was no generated error on this line of my script which was odd to me
A problem has been reported to me that uploading through fckEditor will not work. After messing about with some settings it turns out that running php files in the fckEditor folder will not work and an Error 500 is returned. When I checked the log files the message in the subject was returned. The script is simple:
<?php
echo phpinfo();
?>
When I run this script from power/test.php, it works. It's only when running scripts from any folder within fckEditor/ that doesn't work.
I am using php 5.2.9 and Apache 1.3.42.
Sorted.
I thought this would be down to permissions so I gave everything 777 thinking that would account for everything. It turns out I gave to many permissions, directories need 755 and files need 644.
Hope this helps someone else.