I was upgrading my Symfony 2 project, which works with the lws_memcache Bundle.
Now my I get the following error:
ClassNotFoundException in LoggingMemcache.php line 4:
Attempted to load class "MemcachePool" from the global namespace.
Did you forget a "use" statement?
The File lies in the vendor of the lws_memcache Bundle, so I can't change the code.
My memcached Server is on the version 1.4.14, the bundle itself is the newest verison.
This is what my IDE (PHPStorm 8) shows me when I hover over the Class \MemcachePool in the vendor code.
Multiple definitions exist for class MemcachePool less... (Strg+F1)
Undefined class: Declaration of referenced class is not found in
built-in library and project files. Multiple declarations: this
version of IDE will have problems with completion, member resolution
and inheritance analysis for all classes that have multiple
definitions in project files (regardless of includes).
Is there something I can do about it?
LswMemcacheBundle bundle is compatible with memcache 3.0.6 or higher. I was having the same error with php-memcache 2.2.x.
Try upgrading your php-memcache to the new one (3.0.8), but first you need to edit the formula and setup the flags brew edit php56-memcache :
. 20 safe_phpize
. 21
+ 22 ENV['MACOSX_DEPLOYMENT_TARGET'] = '10.11'
+ 23 ENV['CFLAGS'] = '-fgnu89-inline'
+ 24 ENV['LDFLAGS'] = '-fgnu89-inline'
+ 25 ENV['CXXFLAGS'] = '-fgnu89-inline'
+ 26
. 27 system "./configure", "--prefix=#{prefix}",
. 28 phpconfig
. 29 system "make"
$ brew uninstall homebrew/php/php56-memcache
$ brew install homebrew/php/php56-memcache --devel
Then restart php-fpm + nginx.
Make sure your config file has a memcache session pool defined.
Try rebooting the server.
I had the same issue when installing LwsMemcache in my symfony project. I received the exact same error on production as the one above, but on my dev box, It was a different error (can't remember what it said), but had to do with php5 and memcache not working together.
restarting the services for nginx and php5-fpm did not work. I had to reboot and it works fine.
Related
As the title says, I have a VPS running on CentOS 7, I installed all the requisites for Laravel, PHP 7.3, but it still giving me 'Server Error 500'.
Note that this is a fresh installation of Laravel with composer.
My CentOS version is CentOS Linux release 7.2.1511 (Core)
PHP version is PHP 7.3.6 (cli)
I manually installed all the necessary modules from PHP
What I have already tried
I already did quite a lot of research:
Laravel giving 500 internal error on centos 7 with apache and php 7
I followed what the answer to that questions says and still the same for me.
I did also set up permissions correctly following this other post:
How to set up File Permissions for Laravel 5 (and others)
Also these ones
Getting a 500 Internal Server Error on Laravel 5+ Ubuntu 14.04
https://www.ionos.com/community/server-cloud-infrastructure/apache/how-to-fix-http-error-code-500-internal-server-error/
And a bunch of more articles I read on another websites.
These are the permissions for the project folder:
drwxr-xr-x 13 apache apache 4096 May 31 05:23 laravel
And for storage:
drwxr-xr-x 5 apache apache 4096 May 31 04:44 storage
Tried generating the key and got this:
[root#server laravel]# php artisan key:generate
ErrorException : file_get_contents(/var/www/laravel/.env): failed to open stream: No such file or directory
at /var/www/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Console/KeyGenerateCommand.php:96
92| {
93| file_put_contents($this->laravel->environmentFilePath(), preg_replace(
94| $this->keyReplacementPattern(),
95| 'APP_KEY='.$key,
> 96| file_get_contents($this->laravel->environmentFilePath())
97| ));
98| }
99|
100| /**
Exception trace:
1 file_get_contents("/var/www/laravel/.env")
/var/www/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Console/KeyGenerateCommand.php:96
2 Illuminate\Foundation\Console\KeyGenerateCommand::writeNewEnvironmentFileWith("base64:soTdeaCmsY1ELnpJLCcYkBJjY6SWiLYwY+Mvoxl9wOw=")
/var/www/laravel/vendor/laravel/framework/src/Illuminate/Foundation/Console/KeyGenerateCommand.php:80
Please use the argument -v to see more details.
[root#server laravel]#
Seems like you miss the Laravel environment configuration file.
In a fresh Laravel installation you should have a .env.example file. Duplicate that one and rename it to .env then run the php artisan key:generate command.
Did you created the var/www/laravel/.env file from your var/www/laravel/.env.example file?
So, I fixed it configuring properly the .env and generating a key as #mdexp mentioned.
So for everyone having problems, check the links in my question and set everything correctly
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 am running into an issue with a customer's Drupal sites. He has a number of D6 installs, and a new D7 that he's just starting on. All of these sites are on the same shared hosting package.
The problem is when running certain drush commands only on the D7 site. There are no issues on the D6 sites. The specific error for drush up on the D7 site follows:
foo#bar [~/www/foo]# drush up
Command pm-update needs a higher bootstrap level to run - you will need to invoke drush [error]
from a more functional Drupal environment to run this command.
Command pm-update needs the following modules installed/enabled to run: update. [error]
The drush command 'up' could not be executed. [error]
Drush was not able to start (bootstrap) the Drupal database. [error]
Hint: This may occur when Drush is trying to:
* bootstrap a site that has not been installed or does not have a configured database. In
this case you can select another site with a working database setup by specifying the URI
to use with the --uri parameter on the command line. See `drush topic docs-aliases` for
details.
* connect the database through a socket. The socket file may be wrong or the php-cli may
have no access to it in a jailed shell. See http://drupal.org/node/1428638 for details.
Drush was attempting to connect to:
Drupal version : 7.28
Site URI : http://default
Database driver : mysql
Database username : username_foo
Database name : database_foo
PHP configuration :
PHP OS : Linux
Drush version : 7.0-dev
Drush temp directory : /tmp
Drush configuration :
Drush alias files :
Drupal root : /home/foo/www/foo
Site path : sites/default
Everything I can find (and indeed the link in the error message) say the solution is to change the host value in the settings.php file from localhost to 127.0.0.1. However, this has not been the solution for us.
The frontend site has no problems connecting to the database, and drush itself seemingly does in many cases too.
drush sql-connect will generate a string that you can use to connect to MySQL.
drush sql-cli will successfully connect to MySQL
The settings.php file is definitely in a folder called default (path: www/foo/sites/default) and I get the exact same error when specifying --root and --uri options.
Drush was originally a ~5.x release, and it had the same issues. We updated to the ~7.x to try to eliminate the error. The host value in settings.php has been localhost as well as 127.0.0.1 with equally poor results.
We've verified that MySQL is available via socket from the PHP CLI. Drush is up to date and a fresh install. The Drupal 7 site is a brand new fresh install.
I'm at a loss. Why would this work with the D6 sites, but not the D7? Any suggestions?
Is your settings.php file in a folder called 'default'? If not, you might need to tell Drush where to find it by using --uri=mysite.com or -l mysite.com.
There are several ways to specify which Drupal site Drush will target. The most basic option is fairly verbose; run:
$ drush --root=/path/to/drupal --uri=http://example.com status
You can do the same thing with a slightly different syntax:
$ drush /path/to/drupal#example.com status
You can also specify the Drupal site implicitly, by setting the cwd to the folder that contains the settings.php file for your site:
cd /path/to/drupal/sites/default # or /path/to/drupal/sites/mysite.com, as appropriate
$ drush status
In all of the cases above, if settings.php is in a folder called "default", then you do not need to specify the --uri component; you may, for example, cd /path/to/drupal followed by drush status, and the correct Drupal site will be found. If settings.php is not in a folder named 'default', then you will need to either specify --uri, or cd to the folder that contains the settings.php file.
Source
According to this message:
pm-update needs the following modules installed/enabled to run: update
Drush requires Update module to be enabled, so the following command should fix the problem:
drush -y en update
I know that I have downloaded a Symfony2 project and started with but I have updated my vendor several times and I want to know which version of symfony I have
Any idea ?
Run app/console --version (for Symfony3: bin/console --version), it should give you a pretty good idea. On a random project of mine, the output is:
Symfony version 2.2.0-DEV - app/dev/debug
If you can't access the console, try reading symfony/src/Symfony/Component/HttpKernel/Kernel.php, where the version is hardcoded, for instance:
const VERSION = '2.2.0';
Just in case you are wondering, console creates an instance of Symfony\Bundle\FrameworkBundle\Console\Application. In this class constructor, it uses Symfony\Component\HttpKernel\Kernel::VERSION to initialize its parent constructor.
Although there are already many good answers I'd like to add an option that hasn't been mentioned. Using the command:
php bin/console about
you can get many details about the current project. The first section is about Symfony itself and looks like this:
-------------------- -------------------------------------------
Symfony
-------------------- -------------------------------------------
Version 4.2.3
End of maintenance 07/2019
End of life 01/2020
-------------------- -------------------------------------------
I find the other information besides the version number very useful.
There are also other sections providing details about the (framework) Kernel, PHP, Environment.
Another way is to look at the source for Symfony\Component\HttpKernel\Kernel for where const VERSION is defined. Example on GitHub
Locally this would be located in vendor/symfony/symfony/src/Symfony/Component/HttpKernel/Kernel.php.
Use the following command in your Terminal/Command Prompt:
php bin/console --version
This will give you your Symfony Version.
also you can check the version of symfony and versions of all other installed packages by running
composer show
or
composer show | grep sonata
to get versions of specific packages like sonata etc.
If you want to dynamicallly display your Symfony 2 version in pages, for example in footer, you can do it this way.
Create a service:
<?php
namespace Project\Bundle\DuBundle\Twig;
class SymfonyVersionExtension extends \Twig_Extension
{
public function getFunctions()
{
return array(
//this is the name of the function you will use in twig
new \Twig_SimpleFunction('symfony_version', array($this, 'b'))
);
}
public function getName()
{
//return 'number_employees';
return 'symfony_version_extension';
}
public function b()
{
$symfony_version = \Symfony\Component\HttpKernel\Kernel::VERSION;
return $symfony_version;
}
}
Register in service.yml
dut.twig.symfony_version_extension:
class: Project\Bundle\DutBundle\Twig\SymfonyVersionExtension
tags:
- { name: twig.extension }
#arguments: []
And you can call it anywhere. In Controller, wrap it in JSON, or in pages example footer
<p> Built With Symfony {{ symfony_version() }} Version MIT License</p>
Now every time you run composer update to update your vendor, symfony version will also automatically update in your template.I know this is overkill but this is how I do it in my projects and it is working.
we can find the symfony version using Kernel.php file but problem is the Location of Kernal Will changes from version to version (Better Do File Search in you Project Directory)
in symfony 3.0 :
my_project\vendor\symfony\symfony\src\Symfony\Component\HttpKernel\Kernel.php
Check from Controller/ PHP File
$symfony_version = \Symfony\Component\HttpKernel\Kernel::VERSION;
echo $symfony_version; // this will return version; **o/p:3.0.4-DEV**
if you trying with version symfony
please try with
symfony 2 +
cmd>php app/console --version
symfony 3+
cmd>php bin/console --version
for example
D:project>php bin/console --version
Symfony 3.2.8 (kernel: app, env: dev, debug: true)
For Symfony 3.4
Check the constant in this file vendor/symfony/http-kernel/Kernel.php
const VERSION = '3.4.3';
OR
composer show | grep symfony/http-kernel
From inside your Symfony project, you can get the value in PHP this way:
$symfony_version = \Symfony\Component\HttpKernel\Kernel::VERSION;
Maybe the anwswers here are obsolete... in any case, for me running Symfony 4, it is easy
Just type symfony -V from the command line.
This page is the top Google result for search which version symfony using, and the top answers probably don't work anymore.
Apparently I'm on Symfony 5, after running symfony new aqua_note (from SymfonyCasts recommendation).
I had to ultimately run grep -r VERSION . | grep Kernel to see ./vendor/symfony/http-kernel/Kernel.php: public const VERSION = '5.4.2';... at least I think that's correct now.
if you are in app_dev, you can find symfony version at the bottom left corner of the page
I'm running a Rackspace cloud server CentOs + apache2 + php 5.4 + pcntl module with a basic Kohana php framework with a mongoDb task module that forks children processes. I get the following error if I try to run more then 1 child task process at the same time:
Unable to connect to MongoDB server at Interrupted system call
According to the mongoDb task module author the issue is not related to code but perhaps the mongoDb driver or the server.
Does anyone know what the error means and/or what may be the cause?
Full error output:
0 /var/www/.../modules/mangodb/classes/mangodb.php(370):
MangoDB->connect()
1 /var/www/.../modules/mangodb/classes/mangodb.php(173):
MangoDB->_call('command', Array, Array)
2 /var/www/.../modules/mangotask/classes/model/queue/task.php(33):
MangoDB->command(Array)
3 /var/www/.../modules/mangoQueue/classes/controller/daemon.php(232):
Model_Queue_Task->get_next()
4 /var/www/.../modules/mangoQueue/classes/controller/daemon.php(111):
Controller_Daemon->daemon()
5 [internal function]: Controller_Daemon->action_index()
6 /var/www/.../system/classes/kohana/request/client/internal.php(118):
reflectionMethod->invoke(Object(Controller_Daemon))
7 /var/www/.../system/classes/kohana/request/client.php(64):
Kohana_Request_Client_Internal->execute_request(Object(Request))
8 /var/www/.../system/classes/kohana/request.php(1138):
Kohana_Request_Client->execute(Object(Request))
9 /var/www/.../index.php(109): Kohana_Request->execute()
Driver version 1.2.12 definitely has issues with forking, but this is something that should be resolved in the forthcoming 1.3.0 release. In particular, PHP-426 is one of the later issues to address this problem, as it relocated connection selection from MongoCursor to MongoCursor::doQuery(), allowing the driver to operate correctly after a fork. I would keep an eye out for the next 1.3.0 pre-release (either beta3 or rc1), and certainly when the final 1.3.0 version is released via http://pecl.php.net/package/mongo.