I've recently upgraded to OSX Mavericks and since then, I've started getting the aforementioned error on my development machine. There is no obvious problem in the code (it's an auto generated Yii sample application). What has happened as part of upgrade to Mavericks is:
PHP was upgraded from 5.2.x which bundled with OSX Lion to 5.4.x.
I had to get a Zend Debugger for PHP 5.4 by installing Zend Server, picking up the ZendDebugger.so and uninstalling the Zend Server (all this because Zend doesn't provide a standalone version of their debugger for php 5.4.x).
Ever since, I'm getting this problem after maybe loading and reloading the website a few time. After this error occurs, my web server keeps returning the same error for any other application hosted on localhost. I have to mention that static web pages are served up fine.
I've seen several threads on this topic. Most point out to issues in code where file handles are not being closed properly, thereby crossing the open file limit threshold. I also found this thread which seems to suggest this might be a zend debugger issue. There's also a bug report filed for php 5.2.x. Following the thread here, I tried the following:
$ ulimit -a
which reports:
open files (-n) 256
Also,
sysctl -a | grep files
returns,
kern.maxfiles = 12288
kern.maxfilesperproc = 10240
kern.maxfiles: 12288
kern.maxfilesperproc: 10240
kern.num_files: 3248
Another interesting thread suggests to raise this limit (currently 256) using:
ulimit -n 1024
I've tried everything, but nothing seems to be working. The problem is also not consistently reproducible.
I am wondering is using ulimit -n 1024 is going to affect apache, since from what I've read, it affects the number of files shell can have open.
Any help is appreciated.
EDIT:
Restarting apache helps for a bit, till the error is encountered again.
Leaving the web server idle for a bit (no definite interval) also helps.
Shamelessly stolen from http://docs.basho.com/riak/latest/ops/tuning/open-files-limit/#Mac-OS-X
To check the current limits on your Mac OS X system, run:
$ launchctl limit maxfiles
The last two columns are the soft and hard limits, respectively.
To adjust the maximum open file limits in OS X 10.7 (Lion) or newer, edit /etc/launchd.conf and increase the limits for both values as appropriate.
For example, to set the soft limit to 16384 files, and the hard limit to 32768 files, perform the following steps:
Verify current limits:
$ launchctl limit
cpu unlimited unlimited
filesize unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 10240 10240
Edit (or create) /etc/launchd.conf and increase the limits. Add lines that look like the following (using values appropriate to your environment):
limit maxfiles 16384 32768
Save the file, and restart the system for the new limits to take effect. After restarting, verify the new limits with the launchctl limit command:
$ launchctl limit
cpu unlimited unlimited
filesize unlimited unlimited
data unlimited unlimited
stack 8388608 67104768
core 0 unlimited
rss unlimited unlimited
memlock unlimited unlimited
maxproc 709 1064
maxfiles 16384 32768
If you are experiencing this issue while running Apache you can configure apache to increase the limit:
$ sudo vi /usr/sbin/apachectl
locate:
ULIMIT_MAX_FILES=""
and change this line to something like:
ULIMIT_MAX_FILES="ulimit 4096"
Then:
sudo apachectl restart
This will not work for CLI scripts. But adding a ulimit directly to your ~/.bash_profile (or equivalent) should work for that purpose.
This has the advantage of setting specific limits for apache and your terminal without affecting other apps.
Also, you should be able to adapt this method to other OSs by substituting ulimit with the command applicable to that environment.
I was running into the same issue on El Capitain. Found an article here I owes due credit for the solution. Follow the actions below:
Adjusting Open File Limits
To adjust open files limits on a system-wide basis on Yosemite and above, you need to create two configuration files. The first is a property list (aka plist) file in /Library/LaunchDaemons/limit.maxfiles.plist that contains the following XML configuration:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>limit.maxfiles</string>
<key>ProgramArguments</key>
<array>
<string>launchctl</string>
<string>limit</string>
<string>maxfiles</string>
<string>65536</string>
<string>65536</string>
</array>
<key>RunAtLoad</key>
<true/>
<key>ServiceIPC</key>
<false/>
</dict>
</plist>
This will set the open files limit to 65536. The second plist configuration file should be stored in /Library/LaunchDaemons/limit.maxproc.plist with the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple/DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>limit.maxproc</string>
<key>ProgramArguments</key>
<array>
<string>launchctl</string>
<string>limit</string>
<string>maxproc</string>
<string>2048</string>
<string>2048</string>
</array>
<key>RunAtLoad</key>
<true />
<key>ServiceIPC</key>
<false />
</dict>
</plist>
Both plist files must be owned by root:wheel and have permissions -rw-r–r–. Restart the system.
Also its recommended setting them for the user session in .bashrc and add:
ulimit -n 65536
ulimit -u 2048
Hope this helps.
I was probably suffering from information overload. A possible explanation is offered here which I've also mentioned in my original post. I guess I missed the little detail where the OP mentions that he's working on Mac OSX 10.8.x. I'm on 10.9 so I downloaded the zenddebugger.so from the page and things are looking good. Haven't gotten a single too many open files all day.
So, perhaps it was a ZendDebugger issue.
Regarding the debugger patch answer above. Unfortunately the answer provided above won't work for me, as it applies to php versions 5.4 and I must limit myself to php 5.3.
Zend has released version 6.3 of their server, which supports php at 5.3. I have been playing with the installation for a little while (after dropping my ulimit back down to Apple's default) to test it and am not experiencing any problems. Before the upgrade I could not do any php debugging without raising that limit.
Per http://forums.zend.com/viewtopic.php?t=110823&start=10#p219438 I think this was really just a bug in Zend Server that was fixed in 6.2.
Got the same error with running xDebug.
An upgrade solved the issue.
see:
https://superuser.com/questions/787888/too-many-files-open-on-mac-osx-after-running-apache-in-php-with-xdebug-for-som/829413#829413
Related
I'm running a php script via terminal and I get this error message Allowed memory size of 536870912 bytes exhausted.
So i then added ini_set("memory_limit", "4096M"); to the php file and that did not work.
Then i run php --ini to see which loaded cli file (/etc/php/7.4/cli/php.ini) is being used and after editing said file i found that there is no memory limit set in it ini_set("memory_limit", "-1");
I have no idea what's going on (not very linux savvy). Where is it drawing the conclusion that it only has 512M of available memory?
Edit #1: I also did a phpinfo() which said the php.ini file is at /etc/php/7.4/apache2/php.ini so I edited that file as well, still getting the same result (restarted apache and initiated a new terminal window as well)
Edit #2: the script is run by php mylocalphpfile.php -params
Ubuntu 20, php 7.4
Ok found out that the forked script from Github has some references to other dependencies in which the memory_limit is being forced to be 512M.
Removed that line of code form the lib and now it's working.
I'm using the latest PHP packages available from https://launchpad.net/~ondrej/+archive/ubuntu/php .
When I build and install the OCI8 extension, everything appears to be in order, but despite enabling the extension in the PHP-FPM configuration, its presence is not reflected in the output from phpinfo().
The following Gist details the exact process that I'm using to configure, build, and install the OCI8 PHP extension:
https://gist.github.com/cbj4074/fa761f60b6f8db431539d76ebfba828e
The very same process and configuration work perfectly well on Ubuntu 16.04 LTS, so it seems that there is some fundamental difference on Ubuntu 18.04 LTS, whether with the operating system or the PHP packages in question.
As a bit of important (and I suspect relevant to this issue) background information, on Ubuntu 18.04 LTS, the extension fails to load in the CLI environment out-of-the-box, with the error:
PHP Warning: PHP Startup: Unable to load dynamic library '/usr/lib/php/20160303/oci8.so' - libmql1.so: cannot open shared object file: No such file or directory in Unknown on line 0
I resolved the issue like so:
# echo 'LD_LIBRARY_PATH="/opt/oracle/instantclient_12_2"' >> /etc/environment
I thought that perhaps adding the LD_LIBRARY_PATH to the PHP-FPM environment configuration might resolve the equivalent issue there:
# echo "env['LD_LIBRARY_PATH'] = /opt/oracle/instantclient_12_2" >> /etc/php/7.2/fpm/pool.d/www.conf
# systemctl restart php7.2-fpm
This does indeed cause the LD_LIBRARY_PATH value, as specified, to be reflected in both the Environment section of phpinfo() (when rendered via PHP-FPM + NGINX and requested from a browser) and the PHP Variables section, as $_SERVER['LD_LIBRARY_PATH'].
Oddly, even with PHP-FPM's logging set to debug, I don't see any trace of the libmql1.so error that I experience with the CLI. The OCI8 extension simply fails to load, silently. display_startup_errors = On in PHP-FPM's effective php.ini, too.
I elected to see if the OCI8 extension works in Apache, on the same server, and it does, provided I add export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 to /etc/apache2/envvars; in its absense, Apache complains on startup:
PHP Warning: PHP Startup: Unable to load dynamic library 'oci8.so' (tried: /usr/lib/php/20170718/oci8.so (libmql1.so: cannot open shared object file: No such file or directory), /usr/lib/php/20170718/oci8.so.so (/usr/lib/php/20170718/oci8.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0
None of this business with the LD_LIBRARY_PATH is necessary on Ubuntu 16.04 LTS, and based on my observations herein and the comments regarding https://stackoverflow.com/a/45242468/1772379 , that changed in Ubuntu 17.10 and Ubuntu 18.04 LTS.
Has anybody else tried this, on Ubuntu 18.04 LTS, specifically?
I've tried this on two different Vagrant VMs, laravel/homestead box 6.0.0, and ubuntu/bionic64 box v20180509.0.0, and the behavior is the same in both.
Any other ideas would be most appreciated!
EDIT 1:
I asked about this issue on the package maintainer's GitHub tracker and he suggested that the problem stems from failing to set an appropriate RPATH at compile time.
I explain in my reply that I am setting an appropriate value, but the issue remains closed.
I do notice an interesting detail, however, which is that the compiled extension on Ubuntu 18.04 uses RUNPATH (and not RPATH, which is used in Ubuntu 16.04). If PHP-FPM ignores RUNPATH, and looks only for RPATH, it would explain this behavior.
EDIT 2:
This still-open report looks like an excellent candidate for having introduced the observed behavior:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=859732
(discovered through comments on use RPATH but not RUNPATH? )
EDIT 3:
On a commenter's advice, I reexamined updating the ld configuration before building the extension and that resolved the issue! I had tried this before, but must have overlooked something between build attempts:
# echo /opt/oracle/instantclient_12_2 > /etc/ld.so.conf.d/oracle-instantclient.conf
# ldconfig
I still don't know why LD_LIBRARY_PATH doesn't work as it should in this instance, but adding the Instant Client library path to the linker configuration seems a better approach besides.
EDIT 4:
I stated in my previous edit that modifying the ldconfig constitutes a better approach, but came to realize (on a commenter's good advice) that doing so can cause undesirable library conflicts, because the effects are system-wide.
In hindsight, it makes sense to minimize the "collateral damage" from runtime library linkage modifications by limiting them to the execution environment via the LD_LIBRARY_PATH. Accordingly, I am motivated to determine why this does not work on Ubuntu 18.04 LTS.
I feel that I have established definitively that the PHP-FPM daemon ignores LD_LIBRARY_PATH on Ubuntu (and has since at least Ubuntu 16.04 LTS; see Comments for explanation).
The ld.so(8) manpage states (in relation to the order in which runtime library paths are searched):
Using the environment variable LD_LIBRARY_PATH (unless the executable is being run in secure-execution mode; see below). [sic] in which case it is ignored.
As yet, I cannot think of any other reason for which the path would be ignored. Of secure-execution mode, the same document says:
Secure-execution mode
For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary
should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is exe‐
cuted in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may
have a nonzero value for various reasons, including:
* The process's real and effective user IDs differ, or the real and effective group IDs differ. This typically occurs as a result of
executing a set-user-ID or set-group-ID program.
* A process with a non-root user ID executed a binary that conferred capabilities to the process.
* A nonzero value may have been set by a Linux Security Module.
Firstly, Secure-Execution Mode seems not to be in effect, as the PHP executables don't exhibit this flag (AT_SECURE is 0):
LD_SHOW_AUXV=1 /usr/sbin/php-fpm7.1 -daemonize --fpm-config /etc/php/7.1/fpm/php-fpm.conf
AT_SYSINFO_EHDR: 0x7ffc569e1000
AT_HWCAP: 178bfbff
AT_PAGESZ: 4096
AT_CLKTCK: 100
AT_PHDR: 0x55ceab0c4040
AT_PHENT: 56
AT_PHNUM: 9
AT_BASE: 0x7f823c77f000
AT_FLAGS: 0x0
AT_ENTRY: 0x55ceab19e360
AT_UID: 0
AT_EUID: 0
AT_GID: 0
AT_EGID: 0
AT_SECURE: 0
AT_RANDOM: 0x7ffc56962349
AT_HWCAP2: 0x0
AT_EXECFN: /usr/sbin/php-fpm7.1
AT_PLATFORM: x86_64
It occurred to me that the child FPM pool processes might exhibit different AT_SECURE values, but the output is identical for the PHP-FPM daemon itself, as well as any child processes. The parent and the children all have the following values:
# od -t d8 /proc/851/auxv
0000000 33 140722944548864
0000020 16 395049983
0000040 6 4096
0000060 17 100
0000100 3 93903778242624
0000120 4 56
0000140 5 9
0000160 7 140365152313344
0000200 8 0
0000220 9 93903779136352
0000240 11 0
0000260 12 0
0000300 13 0
0000320 14 0
0000340 23 0
0000360 25 140722944193929
0000400 26 0
0000420 31 140722944196579
0000440 15 140722944193945
0000460 0 0
Secondly, none of these reasons seem to apply, given the following:
1) There is no indication that PHP-FPM or its child processes have real and effective user or group IDs that differ (thanks to https://unix.stackexchange.com/a/202359 for this command):
# ps -e -o user= -o ruser= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
# ps -e -o group= -o rgroup= | awk '$1 != $2'
systemd+ systemd-timesync
systemd+ systemd-resolve
beansta+ beanstalkd
message+ messagebus
daemon root
systemd+ systemd-network
2) The binaries in question do not have any capabilities (the following commands produce no output):
# getcap /usr/lib/php/20170718/oci8.so
# getcap -r /opt/oracle/instantclient_12_2/
3) I have ensured that AppArmor is disabled (it doesn't have a policy that should affect PHP-FPM, anyway):
# systemctl disable apparmor
Synchronizing state of apparmor.service with SysV service script with /lib/systemd/systemd-sysv-install.
Executing: /lib/systemd/systemd-sysv-install disable apparmor
# reboot
# aa-status
apparmor module is loaded.
0 profiles are loaded.
0 profiles are in enforce mode.
0 profiles are in complain mode.
0 processes have profiles defined.
0 processes are in enforce mode.
0 processes are in complain mode.
0 processes are unconfined but have a profile defined.
So, why does PHP-FPM ignore LD_LIBRARY_PATH, if not for any of the aforementioned reasons?
EDIT 5 (Solution):
An astute commenter, #vinc17 , points-out that on systems running systemd, environment variables, such as LD_LIBRARY_PATH, are not necessarily propagated to processes that are started via a systemd Unit.
In other words, PHP-FPM isn't "ignoring" LD_LIBRARY_PATH, but rather, it is not being conveyed to the process. And attempts to set LD_LIBRARY_PATH within the PHP-FPM configuration are futile, because it's too late to do anything useful with the value.
On this advice, it occurred to me to set LD_LIBRARY_PATH in the systemd context, namely, in the Unit file(s) that start the PHP-FPM daemon(s), in which case PHP-FPM loads the OCI8 extension successfully.
Needless to say, we want to avoid editing the package maintainer's file (to avoid conflicts during future upgrades), so we extend it instead:
# mkdir /etc/systemd/system/php7.1-fpm.service.d
# touch /etc/systemd/system/php7.1-fpm.service.d/environment.conf
To this file we add the following:
[Service]
Environment=LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2
And to make the change effective:
# systemctl daemon-reload
# systemctl restart php7.1-fpm
For a more complete example, which addresses multiple co-installed PHP versions, please see my post at https://github.com/oerdnj/deb.sury.org/issues/865#issuecomment-395441936 .
First, Debian bug 859732 is a completely different issue (I would even say an opposite issue): for this bug, several versions of the library are present in the search path (one in some directory specified by LD_LIBRARY_PATH and a different one in some directory specified by the run path), but the wrong one is chosen by the dynamic linker.
In your case, the problem is that the requested library is not found anywhere in the search path. Note also that in your case, it is PHP that seems to try to open the library (via dlopen?), since the message starts with "PHP Warning:". However, it seems that the mechanisms are the same as with usual dynamic linking.
After installing the library, what you need is at least one of:
Nothing special if the library has been installed in a directory that is searched by default. Since you get an error, this is not your case.
Providing the directory in a run path, which must be specified at compile time of the software that will need the library. The problem is that under Linux, this is not done in standard by the build tools, and it may be complex to do it right without breaking other things. However, in the context of dlopen, the software (here, PHP) may have set up what one can call a "plugin search path", where you can put your libraries.
Providing the directory in LD_LIBRARY_PATH. This is what you tried, but your LD_LIBRARY_PATH seems incorrect. Libraries are usually installed in subdirectories named lib (or lib32 or lib64 in specific cases). So, export LD_LIBRARY_PATH=/opt/oracle/instantclient_12_2 seems wrong. Search for the full pathname of the library oci8.so, and just take the directory part of this pathname for LD_LIBRARY_PATH.
Note: strace may be useful to see what directories are considered to search for the libraries. EDIT: ldd and objdump -p are other useful tools to find what's going on with the search paths.
EDIT 2: Another point to note when choosing to use a run path is that indirect library dependencies are found when RPATH is used, but not when RUNPATH is used (so, in this latter case, all dependencies also need to have a run path if they depend on other libraries so that all libraries can be found without resorting to LD_LIBRARY_PATH). This is documented in recent versions of the ld.so(8) man page:
Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present. Such directories are searched only to find those objects required by DT_NEEDED (direct dependencies) entries and do not apply to those objects' children, which must themselves have their own DT_RUNPATH entries. This is unlike DT_RPATH, which is applied to searches for all children in the dependency tree.
This is probably why, without using LD_LIBRARY_PATH, this was working with 16.04 (where RPATH is used) but not with 18.04 (where RUNPATH is used).
I've installed latest XAMPP server with PHP 7 (update: checked also PHP 7.1) (on my Windows 10 system). Wanted to use opcache, so I enabled it in php.ini.
[opcache]
zend_extension=php_opcache.dll
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
With that change now, and with almost every page refresh, I'm getting this error from Apache:
AH00428: Parent: child process 3748 exited with status 3221226356 -- Restarting.
So, page is loading, and loading... waiting to Apache start again. When I'm turning opcache off (by setting opcache.enable=0), Apache is not restarting and everything works fine (omitting the slower web application topic, of course).
Everything works fine while loading app on XAMPP having PHP 5.6 with enabled opcache.
EDIT (added GIF image):
As you can see, sometimes page refreshes like it should. But sometimes it's refreshing much longer, and Apache is restarting in that moment.
EDIT:
To be honest, I gave up with this application and working with PHP on Windows (was working on it for around 10 years with PHP <= 5.6). It's very hard/impossible (for now) to make PHP 7.x work on that OS (with Opcache). Decided to go with Ubuntu and server created with Docker. Everything is easier to configure (especially with Docker) and works faster. I advise everyone to do the same ;).
Your php_opcache.dll path seems wrong, you need write it like below, it works for me.
[opcache]
zend_extension=C:\xampp\php\ext\php_opcache.dll
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.max_accelerated_files=2000
More details
If your XAMPP comes with PHP 5.5+ by default, opcache already included in the bundle, you will just need to enable it. To enable the extension:
Open php.ini (by default it should be located here: C:\xampp\php\php.ini).
Add this line at the end of the file:
zend_extension=C:\xampp\php\ext\php_opcache.dll
Restart Apache server.
open a php.ini file
Change the ;opcache.enable=1 to opcache.enable=1
Add opcache dll path at the end of the file zend_extension = "C:\xampp\php\ext\php_opcache.dll"
Restart apache
for more reference check this video https://www.youtube.com/watch?v=GvWrNoRDjUY
In case of Xampp, just put the below lines next to [opcache]
zend_extension="C:\xampp\php\ext\php_opcache.dll"
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=256
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
To be honest - do not use xammp. Right now we have a bit better tech stack, to run PHP on Linux servers.
Docker
https://docs.docker.com/docker-for-windows/
Vagrant:
https://www.vagrantup.com/
Both of them are based on linux systems, where most of xammp problems will not have place.
First at all:
This is 2022 and I had a similar problem too with PHP-7.2, not on Xamp, but similar server.
How I've got my problem solved?
If you're here because of that, at first try to go with a default "opcache configuration options". And just above opcache.enable=1 put zend_extension=opcache. Your PHP is smart enough to find the extension. And yeah, there's no need to define the full path if you have defined it here extension_dir = [YOUR PATH] (in php.ini). Of course you can use the full path too, if you want too. The path, probably, it's not a problem if your extension is there (in the folder with all PHP extensions). Did you checked, is it there, your extension?
My problem was in this two options:
opcache.memory_consumption
opcache.interned_strings_buffer
I have no idea why, but I guess this two option should have some balance, because both of them is about memory usage.
So, this had my Apache useless, because it didn't wanted to start
opcache.memory_consumption = 64
opcache.interned_strings_buffer = 32 ;this one BAD
next one works fine!
opcache.memory_consumption = 64
opcache.interned_strings_buffer = 16
this one is works fine too!
opcache.memory_consumption = 128
opcache.interned_strings_buffer = 32
So, as I said, at first try to go with a default values of "opcache configuration options", and later do experiments.
How to check everything works on PHP?
var_dump ( zend_version() );
var_dump ( extension_loaded("opcache") ); // bool(false) cuz it's ZEND
var_dump ( extension_loaded("Zend OPcache") ); // bool(true)
// Next one will give you a lot of data about current opcache usage,
// but of course, only if your extension is enabled.
print_r ( opcache_get_status() );
Default OPcache configuration options you can find here:
https://www.php.net/manual/en/opcache.configuration.php
Creeating directory with appropriate permissions and setting it php.ini worked!
opcache.file_cache=d:\xampp\htdocs\opcache
ThreadStackSize 8388608
Helped me in the similar case. This is a httpd option.
on php.ini add more
zend_extension=opcache
remove comment
opcache.enable=1
opcache.enable_cli=0
opcache.memory_consumption=256
opcache.max_accelerated_files=10000
restart apache
On my development box (thank goodness it's not happening in production—that I know of—yet), as I'm working on a PHP site, I get this occasional error:
Warning:
require_once(filename.php): failed
to open stream: Too many open files in
path/functions.php on line 502
Fatal error: require_once(): Failed opening required 'filename.php'
(include_path='/my/include/path') in
path/functions.php on line 502
Line 502 of functions.php is my "autoload" function which automatically requires PHP files containing classes I use:
function autoload($className)
{
require_once $className . ".php"; // <-- Line 502
}
By an "occasional" error, I mean that it'll work fine for about a day of development, then when I first see this, I can refresh the page and it'll be okay again, then refreshing gives me the same error. This happens just a few times before it starts to show it every time. And sometimes the name of the file it's requiring (I have a script split out into several PHP files) is different... it's not always the first or last or middle files that it bombs on.
Restarting php-fpm seems to solve the symptoms, but not the problem in the long run.
I'm running PHP 5.5.3 on my Mac (OS X 10.8) with nginx 1.4.2 via php-fpm.
Running lsof | grep php-fpm | wc -l tells me that php-fpm has 824 files open. When I examined the actual output, I saw that, along with some .so and .dylib files, the vast majority of lines were like this:
php-fpm 4093 myuser 69u unix 0x45bc1a64810eb32b 0t0 ->(none)
The segment "69u" and the 0x45bc1a6481... number are different on each row. What could this mean? Is this the problem? (ulimit is "unlimited")
Incidentally (though perhaps un-related), there's also one or two of these:
php-fpm 4093 myuser 8u IPv4 0x45bc1a646b0f97b3 0t0 TCP 192.168.1.2:59611->rest.nexmo.com:https (CLOSE_WAIT)
(I have some pages which use HttpRequest (PECL libraries) to call out to the Nexmo API. Are these not being closed properly or something? How can I crack down on those?)
Try to set php-fpm (they're set to infinite by default) to more appropriate values on your needs.
For example:
emergency_restart_threshold = 10
emergency_restart_interval = 1m
process_control_timeout = 10s
Maybe, set this too if your app works with lots of files:
rlimit_files = 1024
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.