I am a journal manager and currently, when adding Announcements, we receive the message: “DB Error: Commands out of sync; you can’t run this command now.” We don’t know why we’re getting the message, but the Announcement posts just fine. How do I fix this?
OJS version 2.4.4.1
Hi @delashalong,
I haven’t seen that message before – but before debugging this in depth, I’d suggest upgrading to a more recent release. OJS 2.4.4-1 is quite old, and it’s not unlikely that the problem is resolved in more recent releases.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi @asmecher,
I’ve passed that information on to the editor, and I think we may take steps toward upgrading this Fall. Thanks for your help!
Best,
Delasha
@asmecher We get this same message (on white screen) in OJS 3.1.2 when trying to start the QuickSubmit plugin if there was some other database activity before that. And if we clear the three caches from the Admin menu, the message is gone and the plugin can be used normally. Another strange detail is that the message is preceded by “ojs2:” although it’s a clean OJS3 installation.
Is there any quick fix for this? Having to clean the caches all the time is getting annoying.
Hi @teog,
Can you try turning on show_stacktrace in config.inc.php, triggering the error, and posting the resulting stack trace here?
Regards,
Alec Smecher
Public Knowledge Project Team
@asmecher I set it on and did the same things in order to trigger the error. There is no more white screen and the associated error (reported in this ticket’s title), but there’s a bunch of new Fatal Errors in log file:
PHP Fatal error: Class 'ADORecordSet_empty' not found in /journal/lib/pkp/controllers/page/PageHandler.inc.php on line 32
ojs2: DB Error: Commands out of sync; you can't run this command now
PHP Fatal error: Unknown: Cannot use output buffering in output buffering display handlers in Unknown on line 0
Strangely though, both the site’s backend and frontend work normally despite all these Fatal Errors - how can that be?!
Also: each time QuickSubmit plugin is fired, a submission is started under the Submissions, and a new submission number reserved/taken permanently in the database. Deleting these bogus submissions takes a lots of time when entering entire volumes (not to mention that it’s burdensome on the database since it creates bogus permanent entries all the time), so is there a quick fix for that also? Surely we don’t need a new-submission entry recorded each time QuickSubmit plugin is accessed (clicked within the backend’s menu).
Perhaps this will help (if I remember it correctly, this started after installing the QuickSubmit plugin): whenever I access the Issues menu option in the backend (either of the submenu options: Future Issues, or Back Issues), the Payments submenu on mouseover looks like so:
and immediately upon switching to any other menu option (for example: Administration, as in the image below), it starts displaying the payment options on mouseover normally - without the need to clean any caches (OJS’s or browser’s):
This dummy submission is unfortunately required for the form UI, and is removed with the “Cancel” button in a recent version of the plugin.
This sounds a lot like a database server issue which is cascading down into PHP. The backend and frontend functionality may appear ok if these errors are only causing failed AJAX calls which aren’t directly affecting the UI. Presumably, a PHP Fatal will result in a HTTP 500 error. If you are comfortable using the browser’s Web Inspector, you can see exactly which calls are failing.
@ ctgraham: since I’m new here: is it the same when you answer a question directed at @ asmecher, and when he does?
Within the community forum, we try to encourage everyone to participate in the discussions where they have knowledge and interest. There are many core contributors to PKP, and we will all contribute whenever we can.
Beyond that general rule, asmecher will be largely unavailable for the next week or two.
Thanks.
Why would you say it’s a server issue?! On the contrary, the above fatal errors are obviously due to the QuickSubmit plugin. There are many other cases reporting problems this plugin causes to OJS3.
The right question to ask here seems this: Why is such a buggy plugin included as an official plugin?
I’m looking primarily at the message DB Error: Commands out of sync; you can't run this command now. This is a database error being thrown to OJS. It is plausible that OJS is triggering this by simultaneous queries within the mysqli driver, but if it is an OJS bug, it seems to be very dependent on some unusual external criteria.
What database driver do you have set in config.inc.php and what database system do you use for your OJS database? What OS platform are you running this under?
As asmecher mentioned earlier, the best way to find this error will likely be to see a full stack trace for each of these error messages.
Actually, clearing of caches takes care of that DB error too. As you can see in this thread, others have reported the same error but as related to Announcements, not the QuickSubmit plugin. So the issue seems with the way OJS3 sets cookies, as with many other errors due to OJS3 cookies bug.
All config.in.php settings are OJS3 default. Server configuration and database are all standard, as in 90% users/configurations: Apache, PHP7, etc.
The above errors are from the stack trace in error.log file which started recording the stack trace since show_stacktrace in config.inc.php was turned On per @ asmecher’s advice (it’s also when the white screen (error 500) stopped occurring.)
A stack trace will include all of the function calls leading up to the error, which is why it is helpful for debugging. You can see an example of what one looks like here:
If you can share the stack trace, this will help us to identify the error.
There really is no such thing as a “standard” configuration. Every server has a specific combination of Apache version, PHP version, Database server, and OS version. This specific combination is important for us to know when a bug is found. For example, I’m not able to reproduce this under Red Hat Enterprise Linux Server release 7.6 (Maipo) with Apache 2.4.6, PHP 7.2.14, and the mysqli driver against Ver 15.1 Distrib 5.5.60-MariaDB.
Can you share a link to “OJS3 cookies bug”? Note that only the “Expire User Sessions” option under the Administration menu relates to OJS cookies. Does the problem resolve if you only Expire User Sessions and do not run the Clear Data Cache and Clear Template Cache options?
As I said (twice), the white screen (error 500) is gone since the stack trace was turned on.
Server configuration:
Apache Version 2.4.39
PHP Version 5.6.40
PHP Version (domain) ea-php70
MySQL Version 10.2.25-MariaDB-cll-lve
Architecture x86_64
Operating System Linux
I don’t expire user sessions so it may not be a cookies bug, but it’s certainly an OJS3 bug because I have to clean the system caches in the Admin menu for the bug to go away:
So the “DB Error” is gone from the logs as well now? This is what I was hoping to get a stack trace on. Even if you don’t see a white screen, a failed AJAX request would still result in a stack trace recorded in the log.
What is the context of this difference in PHP versions? Note that OJS 3.1.2 requires PHP 7.1 or better.
Again, the DB error is gone from the screen as there’s no more white screen (error 500), and it remains (still appears when triggered) in the error.log only.
The first PHP version is the server’s version (as with all other stated settings). The second one is the domain’s PHP version as set in the MultiPHP Manager of Control Panel 80.0 (build 22). It can be set up to 7.3 and can be different for different domains and subdomains.
Hrm. I thought our fatalError() handler would spit out the stacktrace to the PHP error log as well as to the screen, but apparently not.
If you are comfortable modifying the code, we could change line 117 of lib/pkp/includes/functions.inc.php:
error_log($applicationName.$reason);
if (isset($trace)) error_log(var_export($trace, true));
This should output the stacktrace to the PHP error log.
It is very odd that enabling show_stacktrace would suppress an HTTP 500 error and not print the stacktrace to the screen. I’m very curious to see the call stack here, if you are able to produce it.