SuiteCRM 8.1.2 Process Workflow Tasks is not running

[domiserver]

SuiteCRM 8.1.2 Process Workflow Tasks is not running.

I checked the admin >> scheduler >> Process Workflow Tasks and shows
“Status”: Active
“Last Successful Run”: NEVER

I ran this command taken from the admin >> scheduler:
$ sudo crontab -e -u username
… and then added the following line to the crontab file:

• • • • • cd /path-to/legacy; php -f cron.php > /dev/null 2>&1
          

but still the Process Workflow Tasks, last successful Run, shows as NEVER.

I also read this article:

Scheduler Jobs in SuiteCRM in Linux - the Definitive Guide

I checked the other schedulers in admin >> scheduler and none of them have ever run.

Do you have any suggestions?
Thanks in advance.

[diligent]

Can you open a shell with that user and run the php -f cron.php command manually? I assume that the user executing the script is not allowed to.
Pls have a look at your config.php-file, you should see an array like:

 'cron' => 
  array (
    'max_cron_jobs' => 10,
    'max_cron_runtime' => 30,
    'min_cron_interval' => 30,
    'allowed_cron_users' => 
    array (
      0 => 'www-data',
    ),
  ),

the bucket allowed_cron_users might be missing in that file, but you can copy & paste it from here. Your user should be listed here, so e.g.

    'allowed_cron_users' => 
    array (
      0 => 'www-data',
      1 => 'domiserver'
    ),

could already solve your issue.

[pgr]

In the cron command, try also adding a full path to the php excutable, like /usr/bin/php instead of just php

You’ll have to check which is the correct path to use in your system, of course.

[domiserver]

Thanks so much @diligent and @pgr .

Steps taken after your suggestions:

1. I opened a shell with username

2. File ownership username username

3. cron.php file permissions are -rwxr-xr-x

4. Current Cron job

   • • • • • /path-to/public/legacy; php -f cron.php > /dev/null 2>&1

5. I manually ran the php -f cron.php command.

6. I updated the config.php file from

	 'cron' =>
             array (
               'allowed_cron_users' =>
                     array (
                           0 => 'username',
                     ),
             ),

to:

	    'allowed_cron_users' => 
                array (
                  0 => 'www-data',
                 1 => 'username',
                  ),

7. In admin > scheduler > Process Workflow Tasks > Last Successful Run
   The value changed from NEVER to
   LAST SUCCESSFUL RUN: 2022-06-21 01:20 PM

8. After 30 minutes, I noticed the "Last Successful Run: was the same at 01:20 PM, so I ran the command again:
   LAST SUCCESSFUL RUN: 2022-06-21 01:52 PM

9. In order to test the cron job:
   I created a “Web Person Form” and completed the basic questionnaire. The data was inserted as a new lead, but the Workflow to send an email template after 2 minutos was never executed.

10. I tested with a conditional:
    Date created “is less than or equal to” Now - 2 minutes

This Workflow was never executed.

Any ideas?
Thanks again.

[pstevens]

Give us a screen shot of your workflow conditions. Now that we’ve established your cron jobs are running, it must be the workflow conditions (also are any errors in the error log that relate to that specific workflow so we can rule out that it’s erroring out).

[domiserver]

Hi @pstevens, thanks so much for your YouTube videos.

Here is the workflow screen capture.

and here is the scheduler job log for today

and these are the errors taken from the legacy > error_log

[21-Jun-2022 22:15:02 UTC] PHP Warning: session_name(): Cannot change session name when headers already sent in /home/d$
[21-Jun-2022 22:15:02 UTC] PHP Warning: ini_set(): Headers already sent. You cannot change the session module’s ini set$
[21-Jun-2022 22:15:02 UTC] PHP Warning: ini_set(): Headers already sent. You cannot change the session module’s ini set$
[21-Jun-2022 22:15:02 UTC] PHP Fatal error: Uncaught Exception: cron.php is CLI only. in /path-to/public_html/c$

[pstevens]

Ok so the issue is still who is running Cron. The user is not being authorized by the server because it’s viewed as external to run the job (I’m not a server admin expert but that’s how I understand it it) That’s what the running as CLI error is all about. You might want to try something like easycron to trigger the Cron job from an external source. I’ve used this in the past when I run into these kinds of issues. If anyone has a better solution to this problem I’d love to hear it.

[pgr]

Why are running the Workflow “Always” and “On all records”? What are you trying to achieve?

If you just want to react to incoming Leads you should really make it On save.

[diligent]

@pgr

If you just want to react to incoming Leads you should really make it On save.

and this is why:

Speicherplatz steigt dramatisch an

First of all, thanks to all of you who supported me on this issue. @diligent @DJuser @larsschaps I found a temporary solution to reduce the size of data w/o destroying my DB. I guess I have to repeat this once a month as long the the long term solutioin (see below) is not setup. The following sql was copied from the web and modified a little bit, so it suites for me. For everybody who faces the same issue, pls be aware that dropping tables can destroy your DB if you not exactly know what yo…

just for you to know @domiserver so that you can spare yourself this troubleshooting at a later time.

[pstevens]

Just so you know, by commenting that out it will work, but it will also allow cron.php to be run from web through a browser just by navigating to https://yourinstalldirectory/cron.php (this is how easycron does it, but you edit these lines of code to specifically allow easycron to trigger cron.php).

If you’re server isn’t open to the web maybe not such a big deal, but if open to the web someone could theoretically hit that URL over and over and bog up your server.

[domiserver]

Thanks @pgr for your suggestion.

I also read your blog on Workflows where you lay out all the options available:
SuiteCRM Workflows Explained

I have changed the incoming leads to “ONLY ON SAVE” and the second action, email sent after 1 day, to:
RUN: Only in the Scheduler
RUN ON: Modified Records

When I screen captured these settings, I was trying to troubleshoot the workflow.

[domiserver]

Thanks @diligent

In fact when the cron finally ran, it sent 100 emails to leads. I was lucky the email-action was set to my own email.

[domiserver]

Thanks @pstevens for your explanation.

I am taking actions right away to fix this security issue.