I've been away from Laravel/Unix for some time but I have a project to setup and hit some snags. The most recent version of Laravel required PHP >=5.6 so I got that updated, setup my new project with laravel new project and made some modifications to the user/group permissions for storage/ and bootstrap/cache folders as normal.
I'm getting HTTP/500 error from Nginx so I checked the error log and I'm getting this in /var/log/nginx/error.log:
FastCGI sent in stderr: "PHP Message: PHP Fatal Error: Class PDO not found in /home/user/public_html/project/config/database.php on line 16" while reading upstream ... upstream: "fastcgi://unix:/var/run/php5-fpm.sock"
PHP Version 5.6.28-1~dotdeb+7.1
When I check /etc/php5/fpm/php.ini the normal extension=pdo.so and extension=pdo_mysql.so were not there so I added them to test it, however those are being requested in the conf.d folder and PHPINO shows those files being scanned/loaded.
However, later in PHPINFO results, PDO/PDO_MYSQL is not listed
UPDATE
I just attempted to use find /-name pdo.so and the same for pdo_mysql.so to find the path to those files and manually modified the loading configuration files to point to them correctly, started the server and that doesn't change anything.
I apologize this is long. I've spent a couple hours scouring to make sure I wasn't just missing something silly, and I may still be.
Any ideas overlfowers?
Well, after much consternation and fiddling I figured this one out...
There was a recursive / endless loop being created in the php-fpm.conf config as shown here:
include=/etc/php5/fpm/*.conf
This was causing PHP5-FPM .conf to attempt including itself, which I caught in a bootup error: Failed to load configuration file /etc/php5/fpm/php-fpm.conf from /etc/php5/fpm/php-fpm.conf
So I modified that to include=/etc/php5/fpm/conf.d/*.conf and everything started back up and now PDO/PDO_MSYQL is loading.
Related
I am running Laravel on Homestead, and whenever I run any php artisan XXX command, the file named -1 is created in the root directory of the app.
Contents of the file are similar to these ones:
Log opened at 2017-12-22 13:54:00
I: Connecting to configured address/port: 10.0.2.2:9000.
E: Time-out connecting to client. :-(
Log closed at 2017-12-22 13:54:00
I am 99% sure it is related some changes I made in my failed attempts to make XDebug breakpoints work with artisan commands. I have exported some shell variables, as recommended in this answer, but when I run export -p I don't see any of them.
Did anyone have a similar issue? What setting can be causing such behavior?
Following the suggestion of LazyOne, I found the answer:
It seems that paths in .ini file have to be absolute. So instead of:
xdebug.remote_log=~/code/xdebug.log
I had to set it to:
xdebug.remote_log=/home/vagrant/code/xdebug.log
and now it works as supposed to.
Today I meet a strange question:
our project need to online a new module
when I execute artisan down in online environment and visit the site, I found it isn't show the maintenance page, it also show the home page
I check the CheckForMantenance Middleware has aleady add to global route middleware, the down file in storage/framework is exist
I execute php index.php it return the maintenance page, but When I visit the site from brown or curl it show the home page
I also run in test server and local, it all work well
I add a new route for test middlware, and visit the url used by curl and brown, and result is 404, the route does not found
I think it may be caused by router cache, but there is no cache file on bootstrap/cache or storage/framework, because I never open router cache!
I have no idea, so I modify the index file, add write header function at top, and redirect to a error html, the crazy thing happened it also show the home page!!!!!!
What happend? I'm sure the project path is right
Finally I reload the php-fpm and it recovery normal, the maintenance view work, redirect url work, and route normal
I don't understand still now, but I guess it may by caused by opcache?
I open the opcache ext, and use the default setting;
env:
laravel: 5.3
nginx: 1.8.1
php-fpm: 7.0.9 with opcache ext
First check your fpm logs, usually, something like this will pop up (check debug/log levels) between the notices:
[01-Mar-2017 23:59:45] NOTICE: [pool www] child 16951 started
[01-Mar-2017 23:59:48] WARNING: [pool www] child 14754
exited on signal 11 (SIGSEGV - core dumped) after 4393.427133 seconds
from start
You have to disable opcache unfortunately. I've been seeing this issue since php 5.5 all the way to 7.1 , you will also find these in the error logs:
2017/03/02 10:00:24 [error] 30498#30498: *170523 upstream timed out
(110: Connection timed out) while reading response header from upstream,
client: 81.243.144.1xx, server: fake.test.pro,
request: "POST /api/users/53e4203cfd1c46e08d5b570c2c93ff86/items HTTP/1.1",
upstream: "fastcgi://unix:/var/run/php/php7.0-fpm.sock", host: "fake.test.pro",
referrer: "http://fake.test.pro/console"
In particular with Laravel, but I've also seen it on wordpress installations. It stops when I disable opcache on all versions of php-fpm
There are bugreports around on this issue but no fixes so far. I always end up doing this :
[opcache]
; Determines if Zend OPCache is enabled
opcache.enable=0
in /etc/php/7.*/fpm/php.ini files. Then my application is robust again and it costs us 150ms. it sucks.
I had a LAMP application running wordpress and I deleted the whole directory and replaced with new files - php based.
Now, when I go to view my server running CentOS - it just shows a 500 Internal Server error.
I've tried:
restarting server
restarting apache service itself
both completed successfully, but this didn't fix anything. Now, I do not know where to go from here.
apache logs # /usr/local/apache/logs/error_log on apache:
[Tue Apr 22 11:12:15 2014] [error] [] SoftException in Application.cpp:357: UID of script "index.php" is smaller than min_uid
I found the fix myself, this wasn't an error with Mysql at all, but rather a permissions issue with the index.php file I had.
The error, which I found in /usr/local/apache/logs/error_log was:
:is smaller than min_uid Premature end of script headers: index.php
To fix, I did this:
ls -l in the directory causing the issue (mine was public_html)
You should see the index file (e.g. index.php) that should be causing the issue. It is due to a root user having the only permission to the file and not your CPanel (or system) username. (note this system/cpanel name)
Run the following within the errorneous directory(Note: this command must be run within all subdirectories of the primary errorneous directory.):
sudo chown yoursystemuserhere:yoursystemgroupuserhere index.php
or to apply to the whole directory (thanks to #Prix):
sudo chown -R user:group /folder
You're all set.
Further literature here: http://www.inmotionhosting.com/support/website/general-server-setup/uid-smaller-than-min-uid
I hope this helps someone else in the future.
I had similar symptoms on my cPanel VPS - I was able to use easyApache to recompile Apache and PHP which fixed the problem for me.
(I realise my problem was slightly different to yours, but it may be helpful for people in the future who have the same problem I had).
chown -R user.usergroup /path_to_the_directory
Will resolve this. It is basically permission issues.
just install wordpress latest version make sure you have atleast php version 5.3 and above also look global register variable if it off or just delete htacess file from server and see what will happens
generally 500 internal server gives when file permission is missing so you should delete htacess file
I've been battling this annoying issue for quite some time now, and it's bugging me a lot that I can't find any fix for it.
When I use "tail -f" to my error_log file to check for errors on my webserver, one specific error keeps popping up all the time, every visitor and page-refresh generates this issue.
I've been googling and searching here on Stack Overflow for a looong time, but nothing is directly related to the problem.
So the error that is thrown looks like this:
[Fri Aug 17 00:16:23 2012] [error] [client xx.xx.xx.xx]
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php5/20090626/openssl.dll' - /usr/lib/php5/20090626/openssl.dll: cannot open shared object file: No such file or directory in Unknown on line 0, referer: http://mysite.dk/
What could I do?
I have tried to remove OpenSSL, and re-installed it again with no luck. I've tried to upgrade every PHP-related package and still didn't work.
grep -ir ssl /etc/php*
gives:
/etc/php5/cli/conf.d/zend_extensions_psa.ini:extension=openssl.dll
/etc/php5/apache2/conf.d/zend_extensions_psa.ini:extension=openssl.dll
/etc/php5/apache2/php.ini.saved_by_psa.08.03;20:24:;extension=openssl.dll ; moved to conf.d/zend_extensions_psa.ini by Plesk
/etc/php5/apache2/php.ini:;extension=openssl.dll ; moved to conf.d/zend_extensions_psa.ini by Plesk
/etc/php5/conf.d/zend_extensions_psa.ini:extension=openssl.dll
/etc/php5/cgi/conf.d/zend_extensions_psa.ini:extension=openssl.dll
So you've got four copies of zend_extensions_psa.ini and all of them are trying to load this nonexistent file. Edit them all, delete or comment out the lines mentioning openssl.dll, and all should be well.
The Debian package management system treats your modifications to configuration files with great respect. It doesn't undo them when you upgrade or reinstall a package unless you remove the the package with dpkg --purge or install the new one with --force-confnew.
It could be that you have something like this in your PHP configuration (php.ini maybe):
extension_dir=/usr/lib/php5/20090626/
and then
extension=openssl.dll
And it could cause a problem because there is no file like that in a given path. This could be caused by manually copying extensions and/or different extensions installers.
I am getting both modules listed as installed / configured when I use:
php -m
or if I use:
php -i
but when I use:
$m = new Memcache;
// or
$m = new Memcache();
// or
$m = new Memcached();
//or
$m = new Memcached;
I get the following error:
Fatal error: Class 'Memcached' not found
I am running on a Mac - OS X (10.5.7) with default install of apache & php. Additionally, I have memcached running as a daemon on 127.0.0.1:11211 and libmemcache as required by the php-memcached library. I have restarted apache tons of times and even done a machine restart.
Does anyone know why the modules/extensions show up in the command line but not in my phpinfo()? I am literally stumped, after 3 hours of googling, I am just about ready to give up.
Also, please note, my phpinfo() outputs my ini files as follows AND they are both the exact same file:
Configuration File (php.ini) Path: /etc
Loaded Configuration File: /private/etc/php.ini
UPDATE:
Apache is failing to load the extension.
[Fri May 14 04:22:26 2010] [warn]
Init: Session Cache is not configured
[hint: SSLSessionCache] PHP Warning:
PHP Startup: Unable to load dynamic
library
'/usr/lib/php/extensions/no-debug-non-zts-20060613/memcached.so'
- (null) in Unknown on line 0 PHP Warning: PHP Startup: Unable to load
dynamic library
'/usr/lib/php/extensions/no-debug-non-zts-20060613/memcache.so'
- (null) in Unknown on line 0
Does anyone know why or how this would happen? Both of the files referenced above DEFINITELY ARE there. Should I move this question to server fault?
Your webserver is probably using mod_php, which is a seperate bit of code from the standalone (CLI) interpreter. If they are both using the same ini file, and the memcache extension is configured in the ini file, then it sounds like for some reason, the mod_php is failing to load the extension - check your webserver error_log for startup errors.
It may be that the mod_php was compiled without memcache support (most extensions need to have a stub file linked into the php code, even though the bulk of the code is not linked until run time). Or it may be a permissions problem on the shared object file. Or your webserver may be running chroot, and unable to find the extension (which would also mean that although the ini files appear to have the same path, this is relative to different roots).
HTH
C.
because both versions use different php.ini
place your php.ini into location noted in the phpinfo() outout
I would suspect that the issue revolves around permissions. When you run php from comand line, it runs as the user invoking it. When run as an apache module, it runs as "nobody".
I would assume that the memcached.so file, or the directory it's in does not have proper permissions.
I stumpled upon this post and was having the exact same problem with an extension in my php -i but not in phpinfo(). Mine was a permissions problem because of selinux on a CentOS machine. I had to change ownership and permissions and now it is working as expected.
Set php path in environment variables as given below.
Right-click on "My Computer"
Properties
Advanced Tab > Environment Variables
Under System variables, scroll down to find "Path", select and click on Edit.
Add path to your php install on the end (make sure to precede with semi-colon ";"). Example: ";C:\php7"
Click Ok.