0

I am (finally) migrating our Drupal 7 sites to Drupal 10.

The one problem I have not been able to resolve is output from the hook_cron().

Everything appears to execute, whether running on the browser using the special link, clicking on the 'Run cron' button, or as a crontab job. (This is verified by the logger messages, or informational messages which will subsequently appear on the site.)

However, none of the PHP output (for example, echo or print_r()) which worked under Drupal 7 appear on the browser or as an external crontab task. The web page doesn't even refresh. This is problematic because our cronjobs output a lot of debug information that allow us to verify that the tasks ran correctly, and this output is redirected into an email which can be reviewed without accessing the Drupal site. So it is not practical to use the logger or other Drupal mechanisms.

Interestingly, there are scenarios where the output does appear, which might provide a clue as to what the problem is:

  • if I include a call to phpinfo()
  • on certain (but not all) PHP errors, which causes all preceding output to appear

Note that this issue also occurs with the example cron code (cron_example.module) if I try to add echo statements; I have found one other user (on the drupal forum) who also ran into this as part of other questions, but there was no any information on how to resolve it.

I tried flush() in case it's some sort of buffering issue, but to no avail.

function cron_daily_cron() {
  // This output is not shown.
  echo "cron_daily_cron started...";

  // The messenger message is shown.
  \Drupal::logger('cron_daily')->notice('cron_daily_cron started');
  \Drupal::messenger()->addMessage('cron_daily_cron started...', 'info');
  \Drupal::logger('cron_daily')->notice('cron_daily_cron exited');

  // The error output caused by the following line is shown.
  inexistentfunctioncall();

  // This message is not shown.
  echo "cron_daily_cron exited";
}

thank you!

4
  • Thanks, I will investigate our php configuration.It may indeed be unusual, but as I wrote, it's our way to manually verify that the cronjob is working correctly, such as sending timely email notifications. Think of it as proactive debugging, in case an email was sent which should not have, or vice-versa, among other types of issues. We can't just rerun the cronjob to figure out after the fact what happened since it may resend emails, or conditions have changed. Commented Mar 21 at 19:13
  • Is this because of output buffering in Drupal? I didn't know that echoing strings in hook_cron implementations is even supposed to be supported.
    – mona lisa
    Commented Mar 21 at 19:57
  • I tried turning off php.ini variables that might cause the issue, specifically output_buffering and implicit_flush, but no effect. What did work is enclosing all the cron output between ob_start() and ob_get_clean( ) and emailing the buffered output, so this workaround will do. Commented Mar 26 at 1:16
  • This seems to be specific to cron, since all the output from other custom modules, are displayed. Commented Mar 26 at 1:19

1 Answer 1

0

The cron controller returns an empty string with a HTTP status 204 (No Content) by design. Otherwise, they could buffer the output and put it in the response.

However, you can try to run cron via drush

drush cron

This does produce PHP output on the command line when I test it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.