Upgrade to 18.2 fails with existing db

cjohnsonuk

I've now created a sandbox instance with a copy of the 1.18.1 code and a copy of the mariadb.
The sandbox is running the same php-fpm configured using the same php.ini file on the same server. There are 2 additional data bases set up on the same mariadb server as the live one to make sure all the db settings are the same.

Running 1.18.2 new install code against a new empty DB works and i can create tickets, view ticket queues and view admin pages which to me says that the server os etc is compatible with OSTicket 1.18.2

Running 1.18.2 new install code against a copy of the original DB works fine for the admin panel but times out when viewing ticket queues with the error
[Tue Jul 15 16:39:34.813572 2025] [proxy_fcgi:error] [pid 952921] [client xxx.xxx.xxx.xxx:52056] AH01071: Got error 'PHP message: PHP Fatal error: Allowed memory size of 1073741824 bytes exhausted (tried to allocate 8192 bytes) in /var/www/tickets/include/class.orm.php on line 3501', referer: https://tickets.mydomain.com/scp/login.php

So it would appear that the database connection is working but that there is either a configuration issue or content in the DB that it stopping the page from loading for the query from returning any data.

originally the memory_limit in the fph_php php.ini was set to 128M but I changed that to 1024M , restarted the apache and fpm service, checked the change was in place using phpinfo() but the error persisted, just the numbers were different.

The code in class.orm.php and around line 3501 looks to be the same in both 1.18.1 and 1.18.2

Running 1.18.1 code against the the new DB works and i can create tickets, view ticket queues and view admin pages

Running 1.18.1 code against a copy of the original DB works

So it would appear there is an issue in my live database that is stopping the new code base loading agent pages/ticket queues

Any hints on how to identify the issue/resolve it would be greatly appreciated

KevinTheJedi

cjohnsonuk

It sounds to me like you have a ton of data to sift through on the prod db and it doesn’t have enough computing power or resources to handle it so the queries are crapping out. You can look on this forum for previous codebase patches to help with the speed. Even this might help.

I will also say that these days MySQL performs better out of the box compared to MariaDB. MySQL 8.0+ has great performance improvements just by itself. Other than that you need to either optimize the database and/or juice up the database resources so it can compute more faster.

Cheers.

cjohnsonuk

The production and test are running on the same box. There are several other systems running on the same box and 18.1 has never had any issues. All DBs and web application files for production and test are on the same box. I have a copy of the production DB and a new DB, a copy of the 18.1 files and a copy of the 18.2 files for testing. If the production DB works fine with 18.1 code in live and testing then, unless the process for accessing the database is fundamentally different in 18.2 I don't see the symptoms pointing at performance of the server.

The release notes for 18.2 would suggest that there is no change to how the DB is being accessed and the commits listed in the release would suggest only three files have changed: include/class.email.php, include/class.oauth2.php,‎ include/staff/templates/email-oauth2auth.tmpl.php

KevinTheJedi

cjohnsonuk

I must’ve misunderstood you as I thought you meant v1.18.2 works fine with a fresh database but not with an existing db. But you are saying that the existing db works fine in v1.18.1 but not v1.18.2 - please correct me if I’m wrong.

If that’s the case then you should also look at the v1.17.6 release notes. Everything added in v1.17.6 got added to v1.18.2 (same as always).

Cheers.

KevinTheJedi

cjohnsonuk

You can try this and see if it helps:

https://github.com/osTicket/osTicket/pull/6034

And there was a fix (or a few fixes) with some Agent access criteria applied to queries in v1.17.6/v1.18.2. This would have an impact on the Queue queries that run on Agent login especially.

Cheers.