Scheduler Jobs do not run

📦 Install & Upgrade Help
1

Scheduler jobs are not running. This problem seemed to surface after a hardware upgrade (Synology DSM 5 -> DSM 6.2) and an update from v7.8 to v7.10, although I’m not sure precisely when.

Current versions:

  • SuiteCRM v7.10.7
  • Apache 2.4
  • PHP 7.0
    SuiteCRM AOP and AOD are disabled via the Admin menu.
    Performed Admin - Rebuild Schedulers
    Performed Quick repair and rebuild

The crontab file appears to be correct.

I restarted the server to provide a clean break for the system logs.

Logging crond shows a call to cron.php every minute, which looks proper to me:

[quote]log_it: (root 6822) CMD (cd /volume1/web/sugarcrm; php -f cron.php > /dev/null 2>&1 )
log_it: (root 7005) CMD (cd /volume1/web/sugarcrm; php -f cron.php > /dev/null 2>&1 )
log_it: (root 7203) CMD (cd /volume1/web/sugarcrm; php -f cron.php > /dev/null 2>&1 )
log_it: (root 7390) CMD (cd /volume1/web/sugarcrm; php -f cron.php > /dev/null 2>&1 )
log_it: (root 7583) CMD (cd /volume1/web/sugarcrm; php -f cron.php > /dev/null 2>&1 )[/quote]

No relevant entries in Apache, Nginix, or Sugarcrm logs.

No entries in any of the SuiteCRM scheduler job logs.

PHP log shows:

The file view.detail.php dates from before the update from 7.8 -> 7.10

I wouldn’t think this php error would cause a complete failure of schedulers to run. Any ideas?

Thanks.

2

Update: the fix to the PHP problem is here: https://github.com/salesagility/SuiteCRM/pull/4267/commits/0ff042fdf0aef109c15ee98b5da523f7936d9a84

However, while it fixed the PHP error, it made no change to the scheduler results.

Now, now scheduler jobs do not run, and there are no error message anywhere that I can find.

Manually running php -f cron.php does not produce any errors.

3

Update:

Never returns from this call, in entryPoint.php

$db = DBManagerFactory::getInstance();

No error message. Apparently it just quits at the return from DBManagerFactory. This is really strange, since most of the rest of SuiteCRM seems to work ok.

4

Update:

It’s failing to connect the dtabase at DBManagerFactory function getInstance, here:

self::$instances[$instanceName]->connect($config, true);

Most of the time this call works fine. However, when called via cron.php, it not only fails to connect, but improperly returns, and instead of executing the next php statement, it ends up wandering around and re-entering getInstance from the top.

AFAIK, all other SuiteCRM functions that use the database are working, so it would seem that config.php is correctly configured

config.php

  'dbconfig' => 
  array (
    'db_host_name' => '127.0.0.1:3307',
    'db_host_instance' => 'SQLEXPRESS',
    'db_user_name' => 'root',
    'db_password' => 'nnnnn',
    'db_name' => 'sugarcrm',
    'db_type' => 'mysqli',
    'db_port' => '',
    'db_manager' => 'MysqliManager',
  ),
  'dbconfigoption' => 
  array (
    'persistent' => true,
    'autofree' => false,
    'debug' => 0,
    'ssl' => false,
    'collation' => 'utf8_general_ci',
  ),

Any help would be appreciated.

5

Problem solved.
When updating the Synology server (both hardware and DSM), PHP 7.0 was automatically added. SuiteCRM is running on php5.6, but it appears that when cron executes a command, php70 is used. This appears to have corrupted the stack somehow, so calls to subroutines did not return properly.

The fix: put this line in crontab, to force use of php56
cd /volume1/web/sugarcrm; php56 -f cron.php > /dev/null 2>&1

Other weirdness: executing php -v from the shell resulted in version 5.6 being returned, but executing the command the original
php -f cron.php
from the command line did not work; but
php56 -f cron.php
does work from the command line.

SuiteCRM is recommended to run on php7, but none of the Synology controls appear to allow it.

I hope this helps someone.

6

More info:
The problem is not PHP7; rather, Synology uses php 5.6.11 for the shell and cron, and packages, including SugarCRM/SuiteCRM use php 5.6.36, which is the version installed as a package.

So the problem is an incompatibility between which php5.6 versions are used. My suggestion above fixes the problem.

Synology responds:

  • This php 5.6 behavior is intended
  • There is no documentation describing it.
  • There is no plan to change it.
  • There is no plan to allow the user to change php version bindings for packages. Once installed as php5.6, you cannot change to php7.0, even if the package would otherwise allow it.
7

Do, did you fix the problem?
I have the same problem with a brand-new installation.

8

See post #70149 above.

9

i have tried but still the same issue …