Ubuntu 24.04 behaves strange after update

Icinga Web
1

I recently upgraded an ubuntu 24.04 from icingaweb2 2.12.2 and icingadb-1.1.3
and after the update icingadb throws the following error.

Fatal error: Declaration of Predis\Connection\Resource\Stream::seek(int $offset, int $whence = Predis\Connection\Resource\SEEK_SET): void must be compatible with Psr\Http\Message\StreamInterface::seek($offset, $whence = Psr\Http\Message\SEEK_SET) in /usr/share/icinga-php/vendor/vendor/predis/predis/src/Connection/Resource/Stream.php on line 163

Everything else works and of course the error disappears if I disable the icingadb module

I reinstalled icingaweb2 and everything even with pruge, nothing helped.

Do you have any idea what can cause this issue or how to fix it?

Best Regards
Nicolas

Edit:
I put a litte bit more work in it and it was a outdated library in a custom module.
the module uses a not so recent version of psr/http-message

as soon as I delete the module it works again

But I checked the 2 files mentioned in the error.
and the definitions of the functions in the 2 files differ on the ubuntu 24.04 package

Edit2: after another purge the files are ok and contain the same definition of the correct interface

  • Icinga Web 2 version 2.12.6
  • icinga/icinga-php-library 0.18.1
  • icinga/icinga-php-thirdparty 0.14.0
  • Used modules and their versions (System - About) icingadb 1.3.0
  • Web browser used
  • Icinga 2 version used (icinga2 --version)
  • PHP version used (php --version) 8.3
  • Server operating system and version ubuntu 24.04
2

Lessons Learned:
don’t provide any library provided by icinga-php-thirdparty

I will do something like this:

  "replace": {
    "psr/http-client": "*",
    "psr/http-factory": "*",
    "psr/http-message": "*",
    "guzzlehttp/guzzle": "*",
    "guzzlehttp/promise": "*",
    "guzzlehttp/psr7": "*",
    "symfony/deprecation-contracts": "*",
    "ralouphie/getallheaders": "*"
  }

in my composer files and hope that this is the right approach of preventing future problems with duplicate libraries

3

This is a known problem we have ourselves. The issue is that PHP’s autoloader doesn’t really allow to control conflicting versions of a given library. Hence why we also have multiple installs of several libraries due to icinga-php-library.

Beware of using the replace approach, as this way you may end up with a race condition, in case something requires a replaced part that isn’t registered in the autoloader yet.

But since the parts you replace are all part of icinga-php-thirdparty, this shouldn’t be an issue since libraries are always loaded before modules.

2 Likes