1.1.0 beta1 installation fails on Debian 'jessie' with nginx + php-fpm

[tomreyn]

Thanks for your work on ElkArte.

Yesterday, I was trying to install ElkArte 1.1.0 beta1 on Debian GNU/Linux 8.5 (jessie) Nginx 1.6.2-5+deb8u2, PHP-FPM 5.6.22+dfsg-0+deb8u1, Percona (MySQL) Server 5.6.30-76.3-1.jessie.

I dropped all tables in a previously created database, ensures it uses UTF-8 collation and setup a MySQL user to have access to it. I downloaded the release ZIP package and unpacked it into a subdirectory of /data/srv/www/ where a previously existing nginx virtual host pointed to and still does. This virtual host is setup to redirect any HTTP requests to HTTPS.

Once I accessed the root URL path which points to where I unpacked the files with a web browser, I got redirected to /install/install.php. Arriving there, I got to see a blank page. At the same time, the following was written to the Nginx virtual hosts' log file:

2016/06/27 01:05:09 [error] 23102#0: *1461870 FastCGI sent in stderr: "PHP message: PHP Fatal error:  Cannot redeclare load_possible_databases() in��A���
                                                                                                                                                          on line 476
PHP message: PHP Stack trace:
PHP message: PHP   1. {main}() /data/srv/www/[redacted]/htdocs/install/install.php:0
PHP message: PHP   2. initialize_inputs() /data/srv/www/[redacted]g/htdocs/install/install.php:29" while reading response header from upstream, client: [redacted], server: [redacted], request: "GET /install/install.php HTTP/1.1", upstream: "fastcgi://unix:/var/run/php5-fpm_[redacted].sock:", host: "[redacted]"

Repeat requests just resulted in the same special characters written to the log file (accompanied by the same error message). I'm not sure what exactly is going wrong there but it does seem like a bug in the code - or a lacking feature (maybe some of the setup I have is just not supported, yet - I remember MySQL 5.6 causing some issues for SMF, but forgot the details).

Even if unsupported, the install experience could possibly be improved.

Update: I'd be happy to also respond on FreeNode IRC in #elkarte.

[Vekseid]

Debian Jessie with nginx + php-fpm is basically my testing configuration >_> Hmm.

Apparently CommonCode.php is getting loaded twice in install.php? How is this passing testing?

[emanuele45]

Yes, there is indeed a require_once "more" than necessary, but I've never encountered such an issue... 😮

in install.php the CommonCode.php is first require'd and later require_once'd.
So, in your case, the code is failing on the require_once because is including again the file instead of realize it was already included at the beginning.

By chance, do you have APC installed and enabled?
The easy fix is to remove the require_once (to do), but I'd like to see if we can get where the issue is to avoid it in the future. 😄

[tomreyn]

Thanks for the fast response. I'm happy to try and help to identify the full extent of this issue.

The APC module is not loaded, but XCache, Xdebug and the Zend OPcache are.

Please find below the output generated by print_r(get_loaded_extensions());, run within this FPM pool.

Array
(
    [0] => Core
    [1] => date
    [2] => ereg
    [3] => libxml
    [4] => openssl
    [5] => pcre
    [6] => zlib
    [7] => bcmath
    [8] => bz2
    [9] => calendar
    [10] => ctype
    [11] => dba
    [12] => dom
    [13] => hash
    [14] => fileinfo
    [15] => filter
    [16] => ftp
    [17] => gettext
    [18] => SPL
    [19] => iconv
    [20] => mbstring
    [21] => session
    [22] => posix
    [23] => Reflection
    [24] => standard
    [25] => shmop
    [26] => SimpleXML
    [27] => soap
    [28] => sockets
    [29] => Phar
    [30] => exif
    [31] => sysvmsg
    [32] => sysvsem
    [33] => sysvshm
    [34] => tokenizer
    [35] => wddx
    [36] => xml
    [37] => xmlreader
    [38] => xmlwriter
    [39] => zip
    [40] => cgi-fcgi
    [41] => PDO
    [42] => gd
    [43] => geoip
    [44] => intl
    [45] => json
    [46] => mcrypt
    [47] => mysql
    [48] => mysqli
    [49] => pdo_mysql
    [50] => pdo_sqlite
    [51] => readline
    [52] => sqlite3
    [53] => XCache
    [54] => mhash
    [55] => XCache Optimizer
    [56] => XCache Cacher
    [57] => XCache Coverager
    [58] => Zend OPcache
    [59] => xdebug
)

Please feel free to request any other outputs and configurations as needed.

[Spuds]

Could be the interaction between the built in Zend OPcache and XCache Cacher. You should not run two OPCache engines, and of the two the built in Zend one is the better choice.

Its fine to use Xcache for user data but you you should turn off its cacher in the .ini settings.

An alternative to using Xcache for user data is to use APCu which is APC without any opcache, this is what I use these days (Zend + APCu).

[tomreyn]

You are right, I should not have >1 active opcache. I just made the following changes:
remove: php5-xcache, php5-xdebug
add: php5-apcu

As a result, the above array now looks like this:

Array
(
    [0] => Core
    [1] => date
    [2] => ereg
    [3] => libxml
    [4] => openssl
    [5] => pcre
    [6] => zlib
    [7] => bcmath
    [8] => bz2
    [9] => calendar
    [10] => ctype
    [11] => dba
    [12] => dom
    [13] => hash
    [14] => fileinfo
    [15] => filter
    [16] => ftp
    [17] => gettext
    [18] => SPL
    [19] => iconv
    [20] => mbstring
    [21] => session
    [22] => posix
    [23] => Reflection
    [24] => standard
    [25] => shmop
    [26] => SimpleXML
    [27] => soap
    [28] => sockets
    [29] => Phar
    [30] => exif
    [31] => sysvmsg
    [32] => sysvsem
    [33] => sysvshm
    [34] => tokenizer
    [35] => wddx
    [36] => xml
    [37] => xmlreader
    [38] => xmlwriter
    [39] => zip
    [40] => cgi-fcgi
    [41] => PDO
    [42] => apcu
    [43] => gd
    [44] => geoip
    [45] => intl
    [46] => json
    [47] => mcrypt
    [48] => mysql
    [49] => mysqli
    [50] => pdo_mysql
    [51] => pdo_sqlite
    [52] => readline
    [53] => sqlite3
    [54] => mhash
    [55] => apc
    [56] => Zend OPcache
)

A phpinfo output confirms that "APC support"="Emulated", so I would think this ensures only APCU is active, not APC Opcode caching.

And ... surprise ... I can access the ElkArte installation page just fine.

Looks like you could consider this a user bug. If a warning / friendly workaround for this situtation is possible it might still be nice to have.

[Spuds]

Glad that seems to have fixed it ... I'll leave this open since we need to remove the second require_once anyway.

Agree it would be nice to warn about double opcache, have to see if there is an easy way to check that (can't depend on just the extension being loaded, since you can turn it off in the extension ini) ... something to check.

[Vekseid]

Warning about things like double opcache should really be more of a 'evaluate php installation' script, not a part of Elkarte proper.

[tomreyn]

I tend to agree, but then you might actually want to have it both ways (maybe have the check take place in the background when the admin interface is accessed (post admin authentication)), since environments tend to change over time.

[Vekseid]

It's not that Elkarte shouldn't do it, it's that evaluating a php installation for all sorts of gotchas is a project in its own right, and if we want to put that together, it should be a separate project that Elkarte includes, not some baked-in script.