Cron Jobs are not executed

Thanks for your precise reply!

You could try using directly the URL try http://mysite.tld/sites/all/modules/elysia_cron/cron.php in your browser to test the execution.

Result: White page after about 2 minutes; probably no WSOD (no record in Apache's error log). No record at ./admin/reports/dblog. With debugging turned on and calling http://mysite.tld/sites/all/modules/elysia_cron/cron.php directly, watchdog logs: "No channels ready to be executed, skipping cron."

At ./admin/build/cron/settings, the "Channel" fields in "Single job settings" are all empty. Put an "1" into them, repeaded manual call of 'Elysia Cron', same result: "No channels ready to be executed, skipping cron."

Are you sure cron is enabled? (the "disable" setting is not turned on)

Checked: "Global disable" at ./admin/build/cron/settings is unchecked.

Are you sure you have not specified a cron key or a ip limitation?

Checked: No "Cron key" and no "Allowed hosts" limitation at ./admin/build/cron/settings.

Have you enabled other modules that control cron execution?

Hm... If so, I'm not aware of them. At ./admin/build/modules, 'Elysia Cron' is the only module with "Cron" in the module's name or description.

Try calling the standard http://mysite.tld/cron.php and see if that way the cron runs (calling "/sites/all/..." is not mandatory)

Yes, calling http://mysite.tld/cron.php works as with Vanilla Drupal Cron: Green message "Cron run successful", redirects to ./admin/reports/status. The problem are automated Cron runs in the background.

Try to install the new 2.x.dev version

This to another problem:

$ drush dl elysia_cron-6.x-2.x-dev   [OK]
$ drush updatedb
Drush command terminated abnormally due to an unrecoverable error.                                                                                                 [error]
Error: Cannot redeclare drupal_save_session() (previously declared in /var/www/cinedat/includes/bootstrap.inc:1837) in
/var/www/drupal/sites/all/modules/elysia_cron/elysia_drupalconv.php, line 114

This kills the complete site (WSOD on all pages), thus reverting to elysia_cron-6.x-2.1.

6.x-2.x-dev from 2013-May-03 was updated with the version from 2013-May-22 a few hours ago; I tried to install this new release and didn't encounter the WSOD as described in #2. The visual appearance of the Cron overview page has changed a bit, but so far the behaviour appears to be identical. I'll give an update in a couple of hours.

Yes, absolutely identical behaviour: Manually executing Cron works as usual, but absolutely no scheduling is being performed.

What does "No channels ready to be executed, skipping cron" mean (except that the module refuses to o it's job?

Obviously a "won't fix".

New server, trying 'elysia_cron' again on three sites (in the past decade, I had been using 'ultimate_cron', which also did not work reliably)

Now using 'elysia_cron' 6.x-2.2, LTS version, from Jan 19, 2023 (https://github.com/d6lts/elysia_cron) with PHP 7.3.31-1~deb10u6.

Results as of May 28, 2024 as shown at the respective ./admin/build/cron admin pages:

1) Last run: 24.05.2024 - 23:12
2) Last run: 25.05.2024 - 05:12
3) Last run: 25.05.2024 - 05:12

These were the times I ran cron manually via ./admin/reports/status/run-cron.

According to Legend, everything is in status: "Waiting for execution Job is ready to be executed, and is waiting for system cron call".

So after a decade, still the identical issue: Cron is not automatically executed according to the settings from crontab; the search index becomes quickly stale and also has to be manually updates (e.g. drush search-index); maintenance jobs like cleaning expired access logs or removing older rows from flood and batch table are not executed unattended.

Running cron manually from ./admin/build/cron takes an exec time between 25s, 51s, and 87s, so I guess timeouts should not be an issue. Really odd.