Content Approval Workflow - Failed to steal cronjob part lock

[SalvatorePollaci]

I am using eZ Platform 2.2 Community Edition + Legacy Bridge + Netgen Admin UI and I have followed the following guide http://share.ez.no/learn/ez-publish/creating-a-simple-custom-workflow-event to build a simple content approval workflow. As stated at the end of this guide(https://doc.ez.no/eZ-Publish/Technical-manual/4.x/Reference/Workflow-events/Approve) once the approver has approved a content, the “cronjobs/workflow.php” cronjob must be run for the content to be published completely.

If i run the following command: ` bin/console ezpublish:legacy:script runcronjobs.php -s ngadminui frequent `

I get the following output:

Running script 'runcronjobs.php' in eZ Publish legacy context
Using siteaccess ngadminui for cronjob
Running cronjob part 'frequent'
Running cronjobs/notification.php at: 31/07/2018 8:59 amFailed to steal cronjob part lock.

Forcing to steal the mutex lock: cronjobs/notification.php
Stealing mutex. Old process has run too long.
Completing cronjobs/notification.php at: 31/07/2018 8:59 am
Elapsed time: 00:00:00

Running cronjobs/workflow.php at: 31/07/2018 8:59 am
Forcing to steal the mutex lock: cronjobs/workflow.phpFailed to steal cronjob part lock.

Stealing mutex. Old process has run too long.
Completing cronjobs/workflow.php at: 31/07/2018 8:59 am
Elapsed time: 00:00:00

There are a few eZ Publish forum posts regarding this problem(e.g. http://share.ez.no/forums/developer/runcrnjobs.php-mutex-stealing) but they resolve it setting safe_mode=On. But such php.ini directive has been removed for php7.

How can I resolve this issue?

Thanks

[SalvatorePollaci]

Even if I run such command with the debug option, I get no extra information:

bin/console ezpublish:legacy:script runcronjobs.php -dall -s ngadminui --sql frequent

Running script 'runcronjobs.php' in eZ Publish legacy context
Using siteaccess ngadminui for cronjob
Running cronjob part 'frequent'
Running cronjobs/notification.php at: 31/07/2018 9:41 amFailed to steal cronjob part lock.

Forcing to steal the mutex lock: cronjobs/notification.php
Stealing mutex. Old process has run too long.
Completing cronjobs/notification.php at: 31/07/2018 9:41 am
Elapsed time: 00:00:00

Running cronjobs/workflow.php at: 31/07/2018 9:41 am
Forcing to steal the mutex lock: cronjobs/workflow.phpFailed to steal cronjob part lock.

#################################### DEBUG ####################################

Stealing mutex. Old process has run too long.
Completing cronjobs/workflow.php at: 31/07/2018 9:41 am
Elapsed time: 00:00:00
Timing: ()
Script cronjobs/notification.php starting

Timing: ()
Script cronjobs/notification.php done

Timing: ()
Script cronjobs/workflow.php starting

Timing: ()
Script cronjobs/workflow.php done

Notice: (eZMySQLiDB[db via TCP/IP, on master]::query(0 rows, 0.200 ms) query number per page:0)
BEGIN WORK

Notice: (eZMySQLiDB[db via TCP/IP, on master]::query(0 rows, 0.274 ms) query number per page:1)
COMMIT

Total runtime: 0.2191 sec
Peak memory usage: 39,168.0000 KB
Database Queries: 2
Script cronjobs/notification.php starting 0.16230.0205
Script cronjobs/notification.php done 0.18280.0038
Script cronjobs/workflow.php starting 0.18660.0105
Script cronjobs/workflow.php done 0.1971
Group Ini load:
Load cache: 0.0755 sec (34.4533%), 0.0108 avg sec (7)
Check MTime: 0.0053 sec (2.4094%), 0.0018 avg sec (3)
Find INI Files: 0.0047 sec (2.1581%), 0.0012 avg sec (4)
Parse: 0.0124 sec (5.6424%), 0.0031 avg sec (4)
Save Cache: 0.0332 sec (15.1751%), 0.0083 avg sec (4)
Group Mysql Total:
Database connection: 0.0049 sec (2.2459%), 0.0049 avg sec (1)
Mysqli_queries: 0.0042 sec (1.9296%), 0.0021 avg sec (2)
Group General:
dbfile: 0.0007 sec (0.3108%), 0.0007 avg sec (1)
INI string conversion: 0.0003 sec (0.1356%), 0.0000 avg sec (13)
String conversion: 0.0001 sec (0.0387%), 0.0000 avg sec (13)

[gggeek]

Does it happen all the time? A common cause for that problem is when you have run once the (legacy) cronjob as root and the script crashed. The lock file is then left on disk as being owned by root, and subsequent runs of the cronjobs script by www-data/site-user can not remove that file...