Bug: MongoDB error when attempting to use Tideways on fresh install about vvv HOT 17 OPEN

Similarly, manually including the tableWatch parameter also still results in the same message ("Looks like you haven't done any profiling").

If you can do a quick PR upstream for that, I think the message about not getting any profiling is probably a separate issue related to our collector

from vvv.

Thanks for opening your first issue here! Be sure to follow the issue template and include your OS/Vagrant/VVV versions! Don't forget you can get support in the VVV slack at https://varyingvagrantvagrants.org/docs/en-US/slack/

VVV

VVV Slack Workspace

Join the VVV Slack Workspace

from vvv.

That tideways error also occurred when I had uncommented tideways in extensions/core but hadn't yet uncommented mongodb so, while it may well also be an issue, I am assuming it is unrelated to the mongodb.so issue.

My understanding of the Tideways provisioner was that if MongoDB wasn't installed that it would run the MongoDB provisioner to ensure this.

@Mte90 do you have any thoughts? It's been a while since I used Tideways myself.

The other thing that could have impacted this is PHP versions

from vvv.

I've opened Varying-Vagrant-Vagrants/vvv-utilities#108 to handle Tideways in PHP v8.3, though the default PHP isn't 8.3 so it shouldn't impact this bug

from vvv.

Actually this seems to be a known issue with php 8.1 (and, presumably, 8.2 and 8.3):
https://bugs.launchpad.net/ubuntu/+source/php-mongodb/+bug/1992999

Short StackOverflow discussion on the matter:
https://askubuntu.com/questions/1434953/unable-to-load-dynamic-library-mongodb-so-tried-usr-lib-php-20210902-mongod

I'm going to test with 8.0 and 7.x versions and see where I get.

Launchpad

Bug #1992999 “php8.1-mongodb: mongodb.so parse error at php sta...” : Bugs : php-mongodb package : Ubuntu

I installed a fresh image of 22.04.1 on a Hetzner cloud server apt update && apt upgrade -y and additional apt install php8.1-cli php8.1-mongodb then php-v PHP Warning: PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/lib/php/20210902/mongodb.so (/usr/lib/php/20210902/mongodb.so: undefined symbol: ns_parserr), /usr/lib/php/20210902/mongodb.so.so (/usr/lib/php/20210902/mongodb.so.so: cannot open shared object file: No such file or directory)) in Unknown on line 0

like I ...

Ask Ubuntu

Unable to load dynamic library 'mongodb.so' (tried: /usr/lib/php/20210902/mongodb.so on fresh 22.04.1 LTS

I installed a fresh image updated and upgraded apt nginx-common php8.1-cli php8.1-fpm php8.1-mongodb PHP -v PHP Warning: PHP Startup: Unable to load dynamic library 'mongodb.so' (tried: /usr/lib/...

from vvv.

So we have mongodb because it's how perftools/xhgui-collector stores the data, but that package is deprecated and replaced by https://github.com/perftools/php-profiler which supports other mechanisms such as files etc. This might let us remove mongodb as a dependency.

In the past we've explored this only to find that MongoDB is necessary for certain xhgui features, as were certain versions of PHP

GitHub

GitHub - perftools/php-profiler: A PHP profiling library based on XHGUI Data Collector

A PHP profiling library based on XHGUI Data Collector - GitHub - perftools/php-profiler: A PHP profiling library based on XHGUI Data Collector

from vvv.

it looks like this is the preferred storage mechanism now https://github.com/perftools/php-profiler?tab=readme-ov-file#upload-saver

I also forgot that we'd already made the switch over and use PDO, so maybe mongodb isn't needed afterall? @Mte90 is removing mongodb feasible?

GitHub

GitHub - perftools/php-profiler: A PHP profiling library based on XHGUI Data Collector

A PHP profiling library based on XHGUI Data Collector - GitHub - perftools/php-profiler: A PHP profiling library based on XHGUI Data Collector

from vvv.

nevermind I realise now it's XHGUI that's the problem, not the collector, it supports MongoDB or PDO but using PDO removes features from the GUI, and composer expects the mongo PHP extension.

On the plus side they explicitly support 8.0/8.1 now

from vvv.

I'm seeing now that PDO is set as the default db option for tideways in VVV's xhgui config.

www\default\xhgui\config\config.php:

$defaults = array(
    'debug' => false,
    'save.handler' => 'pdo',
...

Meaning that what I have seen are separate errors.

MongoDB warning

1. MongoDB has a warning where it is looking for its .so file but it does not exist (I haven't been able to find the file anywhere under /etc/php/ nor /usr/lib/php). Provisioning a machine with the mongodb extension (as set by config.yml) will trigger this warning, as will running mongo --version on the machine after it finishes provisioning. I am unsure what the consequences of this warning are. This issue occurs even when I explicitly set my site to use php7.0.
2. Following the previous numbered point, if I set the save.handler in xhgui's config to be mongo.db, I get a 500 internal server error, with no additional user-side information, as soon as I try to access tideways.vvv.test while my site is up.

XHGUI/Tideways error/misbehaviour

1. If I leave save.handler as pdo (its default), accessing tideways.vvv.test gives me the error I listed here.
2. Following the previous numbered point, if I modify xhgui's pdo config (adding the tableWatch parameter to make the custom config closer to the default config in www\default\xhgui\config\config.default.php), that removes the 500 error but tideways.vvv.test will instead say Looks like you haven't done any profiling when I refresh--even after I visit one.wordpress.test?enable-tideways=1.

www\default\xhgui\config\config.php modification:

    'pdo' => array(
        'dsn' => 'sqlite:/tmp/xhgui.sqlite3',
        'user' => null,
        'pass' => null,
        'table' => 'results',
        'tableWatch' => 'watches'
    ),

from vvv.

If I leave save.handler as pdo (its default), accessing tideways.vvv.test gives me the error I listed here.

My editors really struggle with that file but it's missing the error message and only contains the stack trace

MongoDB warning

This implies MongoDB can be jettisoned

from vvv.

My editors really struggle with that file but it's missing the error message and only contains the stack trace

Ah! My bad.

Here's the error belonging to that stack trace:
Notice: Undefined index: tableWatch in /srv/www/default/xhgui/src/ServiceProvider/PdoStorageProvider.php on line 55

from vvv.

0.21.3 is the latest version but our provisioner is pinned with:

noroot git checkout "0.20.4"

does checkout out the 0.21.3 tag help with this?

from vvv.

Varying-Vagrant-Vagrants/vvv-utilities#108 updates the PHP version used to install xhgui and the version it installs

from vvv.

Unfortunately the above error occurs even after changing the provisioner script to pull xhgui 0.21.3 and when including the changes from Varying-Vagrant-Vagrants/vvv-utilities#108. Similarly, manually including the tableWatch parameter also still results in the same message ("Looks like you haven't done any profiling").

from vvv.

@arose-wt that's a shame, would you consider those changes an improvement though? Or did they introduce new issues? I'd like to see if they can be merged so we can continue debugging from a better place, and it sounds like we need to adjust the docs to remove the mongodb mention

from vvv.

I've merged both PRs, does all work as expected for you?

from vvv.

| I've merged both PRs, does all work as expected for you?

I'm having unrelated system issues with my system's ssh/ssh-agent at the moment.
But when I was testing yesterday I had already made the changes, that were included in both PRs, locally, and still had the same outcomes occur. (See my previous comment here)

from vvv.