OJS 3.4.0.1 update fails with no error?

Software Support
,
1

Describe the issue or problem
upgrade from 3.3.0.20 to 3.4.0.1, production server ends without an error

Steps I took leading up to the issue

  1. enable .htaccess deny all”
  2. rm -Rf ojs/api ojs/cache ojs/classes ojs/controllers ojs/cypress.json ojs/dbscripts ojs/docs ojs/help ojs/js ojs/lib ojs/locale ojs/pages ojs/plugins ojs/registry ojs/schemas ojs/styles ojs/templates ojs/tools
  3. cp -R ojs3401/* ojs/
  4. chown -R apache:apache ojs
  5. chmod -R 755 ojs/cache
  6. php ojs/tools/upgrade.php upgrade

What application are you using?
OJS 3.3.0.20 - 3.4.0.1

Additional information

So both the dev and prod servers are starting with same database dump, copied prod ojs and files to the dev server.

development server finishes the upgrade

2025-09-04 10:37:43 [migration: APP\migration\upgrade\v3_4_0\I7470_FixDeprecatedFileStage]

2025-09-04 10:37:43 [note: docs/release-notes/README-3.4.0]

2025-09-04 10:37:43 [migration: PKP\migration\upgrade\v3_4_0\I7249_UpdateUsersUniqueIndex]

2025-09-04 10:37:43 [code: Installer Installer::addPluginVersions]

2025-09-04 10:37:43 [post-install]

but the live server only goes to:

2025-09-04 11:09:05 [migration: APP\migration\upgrade\v3_4_0\I7470_FixDeprecatedFileStage]

2025-09-04 11:09:05 [note: docs/release-notes/README-3.4.0].

the closest to the time in the PHP error log (production server log) is:
[04-Sep-2025 11:09:16 UTC] PHP Warning: Undefined array key “user” in /web/html/ojs/lib/pkp/classes/proxy/ProxyParser.php on line 56
[04-Sep-2025 11:09:16 UTC] PHP Warning: Undefined array key “user” in /web/html/ojs/lib/pkp/classes/proxy/ProxyParser.php on line 56
[04-Sep-2025 11:09:17 UTC] PHP Warning: Undefined array key “user” in /web/html/ojs/lib/pkp/classes/proxy/ProxyParser.php on line 56
[04-Sep-2025 11:09:17 UTC] PHP Warning: Undefined array key “user” in /web/html/ojs/lib/pkp/classes/proxy/ProxyParser.php on line 56
[04-Sep-2025 11:09:18 UTC] PHP Warning: file_put_contents(/web/html/ojs/cache/opcache/667436779-68b9735e1e9b80.75985715.tmp): Failed to open stream: Permission denied in /web/html/ojs/lib/pkp/lib/vendor/elcobvg/laravel-opcache/src/Store.php on line 362
[04-Sep-2025 11:09:18 UTC] PHP Warning: rename(/web/html/ojs/cache/opcache/667436779-68b9735e1e9b80.75985715.tmp,/web/html/ojs/cache/opcache/opcache-b403ab2f1eeb4d665557e1d4a595df60b708715d): No such file or directory in /web/html/ojs/lib/pkp/lib/vendor/elcobvg/laravel-opcache/src/Store.php on line 363
(then these file_put_contents and rename just repeat for different files 2400ish times)

would this be a possible php timeout issue?

server configs are identical. so traffic could be an issue…

2

Hi @jermdouglas,

Are you running the upgrade via the web-based upgrade process, or are you using tools/upgrade.php through the command line?

If it’s the web-based process, then you’re likely encountering an Apache or PHP time limit.

If you’re using the CLI, it’s less likely but still possible that you’re hitting a PHP execution time limit; check your php -i output to see if one is set.

(As the error messages say, you’re also running into file permission problems that should be fixed – but those shouldn’t explain the upgrade’s sudden death.)

Regards,
Alec Smecher
Public Knowledge Project Team

4

using the cli, so using “php ojs/tools/upgrade.php upgrade”
checked php -i:

max_execution_time => 0

max_input_time => -1

so no time limits, I guess that shouldn’t be an issue.

Could the “[migration: PKP\migration\upgrade\v3_4_0\I7249_UpdateUsersUniqueIndex]” be tied to the “PHP Warning: Undefined array key “user” in /web/html/ojs/lib/pkp/classes/proxy/ProxyParser.php on line 56” which then triggered the cache/opcache to not get the correct permissions? Or am I interpreting that wrong?
Of course it still doesn’t explain why with two identical server configs one fails and one succeeds. So if anyone has any ideas to try let me know.

5

Hi @jermdouglas,

Hmm, I don’t see anything here that would explain it to me; would you consider just upgrading on the test server and then moving the upgraded results back to production?

Regards,
Alec Smecher
Public Knowledge Project Team

6

I guess I will have to test that out… thanks for the suggestion (I originally didn’t think that would work, but I guess it makes sense that it would)