What is the content of your cron job? It will help people to replicate the issue

Sorry, should have realized...

It's just a cli-call to run the jobs:

cd $CIVI_ROOT; $PHP bin/cli.php -j $CIVISITE -u $CIVIUSER -p $CIVIPASS $EXECUTE_ALL

And then you want to know which jobs that are run, right ;-)

Since it is sent every five minutes (the interval of my cron-job), and the only jobs that are run "Always" are Mailings scheduler and Participant status processor, it should be one of those.

But "access.php" sounds rather general: "Class that handles all access authorisation routines"

I am just trying to make sure that the issue has enough information for anyone who looks at it to be able to replicate and then debug ;)

JDEBUG isn't defined in any of the bootstrap files (libraries/import.legacy.php or libraries/cms.php) but the includes/framework.php file in each app, and those aren't loaded in our CLI bootstraps because they're application specific.

I'm going to call this not a bug. JDEBUG is used in a lot of places, as well as just checking the configuration file to find if debug mode is enabled (because consistency is overrated). Similar to the JPATH_* base constants, it needs to be defined by all applications.

I don't really understand what you mean by "not a bug". Are you saying that there is some third party application/component that doesn't, but should, set JDEBUG to something just to be a "well-behaved" Joomla app?

Can you point me in some direction of a description of this so I can point there for the application/component developer, once I figure out which one it is. (And I' quite sure that would be the CiviCRM "application" I'm using...)

BTW I'm running Joomla under standard production settings (default error reporting, no debug).

If it is a production environment you should ajust your error reporting first to a lower level "none" makes sense in such cases

Your cron job should have a similar bootstrap to the CLI apps shipped in the cli directory. What they fail to do though is the final step in the includes/framework.php file which is to define the JDEBUG constant (including the libraries/import.legacy.php and libraries/cms.php files only sets up all of the autoloader logic and registers a default global exception handler, those files are independent of the configuration data). Our CLI files do not use the includes/framework.php file because that is written specifically for the web frontend application.

Just add this line: define('JDEBUG', false); and you'll be fine. As I said, it's not a bug, rather one step of the bootstrapping process wasn't included and previously whatever code path was being followed in your cron job didn't run into any code using this constant whereas now it does.

Thanks, that seemed to fix it.