CRON Trouble Since Blesta v4 upgrade

[jwogrady]

I've upgraded to v4 then migrated my install to a new server.  I can manually run the cron job, but it does not work when I add it with `crontab -e` or adding it directly to `cron.d`.  This doesn't seem to be working either....

Quote

• Cron does not seem to complete normally and Settings > Company > Automation shows some hung tasks.
  • Try disabling your cron job, and running the cron manually under Settings > System > Automation. If it runs correctly, you may have a memory issue in your CLI environment with Zend Memory Manager. Some users have reported that appending export USE_ZEND_ALLOC=0; to the beginning of their cron job resolved the issue. When using this method, your cron may look something like this: export USE_ZEND_ALLOC=0; /usr/bin/php /home/user/public_html/blesta/index.php cron

I have applied the v7 hotfix...  I'm not running cPanel...

As of now my file in cron.d looks like this...

*/1 * * * * root /usr/bin/php /super/secret/path/to/install/index.php cron

-  lowered to 1 for testing... 5 has same result....

-  added the root user since in cron.d

Process seems to be running...

root@debian:~# service cron status
● cron.service - Regular background program processing daemon
   Loaded: loaded (/lib/systemd/system/cron.service; enabled)
   Active: active (running) since Wed 2017-03-22 13:07:02 CDT; 22min ago
     Docs: man:cron(8)
 Main PID: 4824 (cron)
   CGroup: /system.slice/cron.service
           └─4824 /usr/sbin/cron -f

Mar 22 13:22:01 argos.zonedock.com CRON[5151]: (root) CMD (/usr/bin/php /super/secret/path/to/blesta/index.php cron)
Mar 22 13:23:01 argos.zonedock.com CRON[5161]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 22 13:23:01 argos.zonedock.com CRON[5162]: (root) CMD (/usr/bin/php /super/secret/path/to/blesta/index.php cron)
Mar 22 13:24:01 argos.zonedock.com CRON[5183]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 22 13:24:01 argos.zonedock.com CRON[5184]: (root) CMD (/usr/bin/php /super/secret/path/to/blesta/index.php cron)
Mar 22 13:25:01 argos.zonedock.com cron[4824]: (*system*blesta) RELOAD (/etc/cron.d/blesta)
Mar 22 13:25:01 argos.zonedock.com CRON[5248]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 22 13:25:01 argos.zonedock.com CRON[5249]: pam_unix(cron:session): session opened for user root by (uid=0)
Mar 22 13:25:01 argos.zonedock.com CRON[5250]: (root) CMD (command -v debian-sa1 > /dev/null && debian-sa1 1 1)
Mar 22 13:25:01 argos.zonedock.com CRON[5251]: (root) CMD (/usr/bin/php /super/secret/path/to/blesta/index.php cron)

but not according to Blesta.... Last run date in attached...

My setup....

/usr/bin/php 

PHP 7.0.17-1~dotdeb+8.1 (cli) ( NTS )
Copyright (c) 1997-2017 The PHP Group
Zend Engine v3.0.0, Copyright (c) 1998-2017 Zend Technologies with Zend OPcache v7.0.17-1~dotdeb+8.1, Copyright (c) 1999-2017, by Zend Technologies

Debian 8.7

[Paul]

14 minutes ago, jwogrady said:

this might be the problem......

when I run direct from the command line.....  How is that possible if I got through the install process?

John
 

Site error: the ionCube PHP Loader needs to be installed. This is a widely used PHP extension for running ionCube protected PHP code, website security and malware blocking.

Please visit get-loader.ioncube.com for install assistance.

Your CLI and Web environments must be different.

php -i | grep php.ini

For the location to the CLI php.ini. Make sure ioncube is loaded from the CLI PHP, then check with: php -i | grep ionCube

[Paul]

30 minutes ago, jwogrady said:

Are there any customer benefits to ionCube? 

Not really no, it just makes it slightly harder to pirate. To be honest, ionCube has been more of a support issue than I care to admit. I'd love to drop it entirely, but some people have voiced objections.

[Michael]

What OS are you using? And what panel are you using?

[jwogrady]

@Licensecart no control panel.  I'm using debian 8.

[Michael]

15 minutes ago, jwogrady said:

@Licensecart no control panel.  I'm using debian 8.

Ubuntu that cron job should work with that default way. I did it with v3.6.x before but it's the same with V4.0.0.

[Nelsa]

What happen when you execute that command directlly in console,does it work?Try to execute cron command in console,if work and blesta register it than you can exclude one side.

 

Example how it looks like on my server(ubuntu 14.04) when ececute  cron command in terminal:

[root@ip-172-31-59-141 ~]# /usr/bin/php /xxxxx/xxxxxx/xxxxxx/xxxxx/index.php cron
Content-type: text/html; charset=UTF-8

Attempting to run all tasks for Nelsahost web hosting service.
All tasks have been completed.
Attempting to run all system tasks.
All system tasks have been completed.

 

[jwogrady]

yes, can run directly from Blesta.

[jwogrady]

my current working theory is I'm running into ulimit restrictions....  Not sure how that is possible if running the cron as a root user....

UPDATE:  I was wrong.  This isn't the problem.

[Nelsa]

Well you can exclude that theory by incresing ulimit with  ulimit -n 10096  or any number ,just keep in mind this number will stay till you are loged in only.If I remeber corectly ulimt default value is 1024

I didn't use crontab directlly for long..long time,but I remeber from that time there are few rules had to be implemnted like every cron must finish with new line character,no file extension at the end...and few others..also some editors could make mess...and many people  save the crontab using the -e option..but that was few years ago..I suppose it was fixed till now.First step is always to run your cron directly in terminal/SSH console to make sure command and script which is executed work than you know for sure it is issue with crontab or with command in file.If that is your production server than you can set this cron on your server or any other server/hosting account or cron provider till you fix that,this will work from every where. 

You can find cron key in settings--->sistem-->automation-->cron key ,just change url,path and key

GET https://yourdomain.tld/blesta/path/?cron_key=blesta_cron_key

 

[Paul]

You should enable error reporting and system debug in the /config/blesta.php config file, and run the cron command via SSH

/usr/bin/php /super/secret/path/to/install/index.php cron

Is there any output?

[jwogrady]

this might be the problem......

when I run direct from the command line.....  How is that possible if I got through the install process?
 

Site error: the ionCube PHP Loader needs to be installed. This is a widely used PHP extension for running ionCube protected PHP code, website security and malware blocking.

Please visit get-loader.ioncube.com for install assistance.

[jwogrady]

51 minutes ago, Paul said:

Your CLI and Web environments must be different.

php -i | grep php.ini

For the location to the CLI php.ini. Make sure ioncube is loaded from the CLI PHP, then check with: php -i | grep ionCube

@Paul

yep, that was the issue.  PHP-FPM uses a different php.ini file...

from my running web server version of php....

cp /etc/php/7.0/fpm/conf.d/00-ioncube.ini /etc/php/7.0/cli/conf.d

php -i | grep php.ini

that did the trick.....

Both issues during the migration stem from your IP protection solutions....  First, issues with the key server... Second, issues with ionCube.

Are there any customer benefits to ionCube? 

Anyways, you guys have been quick to respond and very supportive.   But  then I think about the root causes of the problems.....  Not sure chalking them up to "config issues" on my end is the right answer either....

 

[jwogrady]

27 minutes ago, Paul said:

Not really no, it just makes it slightly harder to pirate. To be honest, ionCube has been more of a support issue than I care to admit. I'd love to drop it entirely, but some people have voiced objections.

hey hey hey, you mean ionCube telling me I need to install this for intrusion protection is BS... lol

Yeah, I understand your dilemma.  I think the marketplace would boom if shifted more towards a WordPress model...  But man, once you move in that direction you have to be all in because there is no going back.

My humble request is don't do what Docker and Magento did......  CE and EE.....  I would rather deal with ionCube than deal with crippleware "community editions".