search

Thomas-Gelf / icingaweb2-module-eventtracker

2 stars 3 forks source link

SCOM Alerts tab doesn't work with PHP 7.4.6 #30

Closed mwaldmueller closed 2 years ago

mwaldmueller commented 2 years ago

After updating from PHP 7.2.5 to PHP 7.4.6 the "SCOM Alerts" tab doesn't work any more, although pdo_dblib was adjusted. All other tabs work as expected.

scom_alerts

Environment

Eventtracker: v0.9.0 PHP: 7.4.6

Thomas-Gelf commented 2 years ago

Please check your PHP INI files, pdlib.so must be loaded - the message shows, that it isn't. Also, please restart php-fpm (or your Apache server, in case you're running PHP as a module) when tweaking the PHP configuration. php -m shows loaded modules on CLI, a PHP file containing <?php phpinfo(); would do a similar (better) job via web. Web and cli are using different configurations.

mwaldmueller commented 2 years ago

pdo_dblib is definitely loaded and works for other views (e.g. "Event Tracker"). Only "SCOM Alerts" doesn't recognise it. Here the output of phpinfo: Bildschirmfoto 2022-06-20 um 15 17 06

Thomas-Gelf commented 2 years ago

Strange. Btw, the Event Tracker view doesn't use an MSSQL connection - only the daemon does. The "SCOM Alerts" is a menu entry for debugging purposes only, this used to be an experiment for an upcoming dedicated SCOM module. Is the daemon successfully polling your SCOM DB?

mwaldmueller commented 2 years ago

Yes, the daemon works as expected and new events are fetched.

Thomas-Gelf commented 2 years ago

Ok, so you shouldn't worry about the failing "SCOM Alerts" link, that view isn't essential for this module. It's just there to show what the daemon would see in your MSSQL DB.

Still, this is strange. Is the error message still the same ("The dblib driver is not currently installed"), or did it change?

mwaldmueller commented 2 years ago

No, the error message is still the same. That's why I opened this issue ;-)

mwaldmueller commented 2 years ago

I'm sorry, the view worked again after a few hours, but the customer didn't inform me. From my point of view you can revert the changes. Thanks for the effort!

Thomas-Gelf commented 2 years ago

Thanks for letting me know, I really was wondering how this could happen. Probably php-fpm hasn't been restarted, and/or that session has still been served from a former php-fpm-process. Anyway, that view was an experiment to prototype an upcoming dedicated SCOM-module. As its query doesn't match 100% what the daemon does internally, it's probably better not to show it at all.