File Password:

To view the content, you need to Sign In or Register.

This XenForo 2.x addon implements an advanced CLI triggered job runner for use with Unix cron as a replacement for the built-in xf:run-jobs command introduced in XF 2.2

The command is called hg:run-jobs and does the same thing that xf:run-jobs does, but with more options and functionality.

Features

Main features of this addon:

• allows commands to process jobs/crons for up to 10 minutes at a time, even when triggered every minute from a cron task (uses a lock file to prevent multiple executions in parallel) - ideal for improving job performance on high traffic sites
• extensive debugging output available for testing and identifying issues with jobs and cron tasks
• drop-in replacement for xf:run-jobs
• command to list all outstanding Jobs hg:show-jobs
• command to list all XF Cron tasks hg:show-crons
• command to execute an XF Cron task hg:run-cron

Requirements

This addon requires PHP 7.0 or higher and has been tested on XenForo v2.2 and v2.3

Installation

Install as per normal addon installation.

Once installed, go to the System and performance options page as change the Job run trigger setting to "Server based trigger"



First, you should test that your job runner is functioning - execute the following command from your CLI:
For example, if your forum root is /srv/www/xenforo/community, then the job runner command would be:
Running this command will execute any outstanding jobs and then finish with a message about whether there are more jobs waiting to be executed or not. When executing this command from cron, it is recommended that you use the --quiet (or -q) flag to suppress output.

Once you are happy that the job runner functions correctly, you will need to create your own cron task to run it on a schedule of your choosing.

NOTE: if you already have a cron task set up to run xf:run-jobs simply disable that and replace it with an identical task which runs hg:run-jobs instead.

Approach #1 using crontab:

It is highly recommended that you have your cron task run as the web server user to prevent potential permission problems.

For example, on Ubuntu with a web server user of www-data, install a cron task by running the following command:
Edit the crontab file and add:
Save the crontab.

Approach #2 using cron.d:

Instead of using a crontab, some Linux distributions create a well-known directory which is automatically checked for cron tasks to execute. In the case of Ubuntu, you can create files in /etc/cron.d/ where you specify the schedule, the user to execute the command as, and the command itself.

Create a file in /etc/cron.d/ with the following contents:
... where webserver-user is changed to the name of the user your web server runs as and change the path to your forum root.

Again, using our previous example where web server user is www-data and our forum root is
/srv/www/xenforo/community, I would execute the following command to create the cron file:
Both options (crontab and cron.d) will execute the job runner every minute, checking for outstanding jobs to be run.

By default, the job runner will run for a maximum of 30 seconds, executing any outstanding jobs until there are no more runnable jobs in the queue.

Upgrading from addon v1.x after upgrading XenForo to v2.2

v2.0 of this addon changes the command name and the maximum permitted run time. Note also that the --time option in v1.x has been renamed to --max-execution-time in line with the core job runner provided in XF v2.2.

To upgrade:

1. Upgrade to XF v2.2 RC2 or later
2. Install v2.0.x of the addon
3. change your unix cron entry to execute hg:run-jobs instead of xf:run-jobs
4. if you use the --time option, rename this to --max-execution-time
5. optional: adjust the --max-execution-time option to anything up to 600 seconds (10 minutes) to allow job processing to take as long as it needs. For example: --max-execution-time=180 will allow the Job Runner to execute for up to 3 minutes at a time

Note: make sure you have "Server based trigger" enabled in the System and performance admin options.




Configuration

You may adjust the maximum execution time of the job runner by specifying the --max-execution-time=[TIME] option on the command line.


For example, to allow the job runner to execute for a maximum of 45 seconds:
This addon uses lock files to prevent multiple job runner commands to execute at the same time, which also allows us to have the command run for longer periods on busy sites.

The maximum execution time allowed is 10 minutes (600 seconds). The command will execute until it finds no more outstanding jobs and then stop - so execution time is typically only a few seconds.


For further customisation of your job execution, you may also adjust the maximum time that each job is permitted to run.
This is configured via a :
The jobMaxRunTime option configures the amount of time in seconds that processing jobs will be allowed to run before they are suspended for further processing on another go-around, if possible. The default setting is optimised for the browser-triggered job runner and so to allow jobs to execute longer in a CLI environment, you may want to adjust this to a higher value.

In general it is suggested that this setting be kept to a relatively small value to avoid the situation where a single very long job may prevent other jobs from executing in a timely manner. Some experimentation may be required to find the optimal value for your server load and forum size. If in doubt, leave it as the default setting of 8 seconds.

Usage

The run-jobs command should be executed automatically using a cron task as per the instructions above.

Show Jobs

The hg:show-jobs command outputs a list of all the currently pending jobs, so you can see how full the jobs queue is.

By default only the next scheduled 100 jobs will be shown, you may use the --all option to show a complete list of all pending jobs.

There should always be at least two jobs showing: the main Cron job and the Upgrade Check job.
Debugging Jobs

There are extensive debugging tools to help identify issues with Jobs and Cron tasks.

To run in debug mode, first disable the Unix cron which runs jobs automatically (don't forget to turn it back on again once you are finished debugging!) and then use the verbosity options (Verbose: -v, Very verbose: -vv or Debug: -vvv) for the hg:run-jobs command to specify the level of output to show on the console.

Output is to the console and is in a format similar to that used by the Monolog library (although we do not use Monolog to generate the output).

For example, Verbose option -v:
The Very Verbose option -vv adds context, typically about the JobResult:
And finally the Debug option -vvv adds extra information about the job:
Custom job debugging

You can add additional debugging to your custom jobs.

Add the following function to your job class to call the logJobProgress function of our Logger class:
Then you can call the log() function in your job code to send information to the console when the Job Runner is executed in verbose mode.

For example - see the test job included in this addon Hampel\JobRunner\Job\TestJob:
The above code will generate the following output when the Job Runner is in debug mode:
No output will be shown when run in quiet mode - and more importantly, if this addon is disabled the logging code will not need to be removed. The important part is the if (!isset(\XF::app['cli.logger'])) return; line, which will abort if our Logger is not available.

Custom Cron task debugging

Using a similar mechanism, we can add debugging code to our custom Cron tasks too:

Add a slightly different function to your Cron tasks to call the log() function of our Logger class:
Then, simply call something like: self::log("some message about something happening", ['key' => 'value']); within your code to output information to the console when the Job Runner is executed in verbose mode.

Logger Trait

There is also a trait you can include in your classes: Hampel\JobRunner\Cli\LoggerTrait which implements some basic logging functions you may call from your code:

• getLogger
• log
• logQuiet (will show even if the -q option is specified for the Job Runner) - use this for critical errors only
• logNormal (will show for no verbosity or higher)
• logVerbose (will show only for the -v option or higher)
• logVeryVerbose (will show only for the -vv option or higher)
• debug (will show only if the -vvv option option is specified for the Job Runner)

There is no need to remove your logging or debugging code from your addon when you deploy - when running hg:run-jobs in normal or quiet mode, none of the output is shown unless it uses logNormal or logQuiet (which should only be used for errors).

Debugging Cron tasks

As of v2.0 beta 3, there are two new commands for working with XF cron tasks:

Show Crons

The hg:show-crons command will list all of your active XF cron tasks
There are three command line options you can specify:

• -a or --all shows all cron tasks, including disabled tasks
• -m or --method includes the class::method for each cron task
• -s or --sort specifies the sort column for the list (date, id or addon)

You can use this tool to quickly identify the ID of the cron task you want to run - which you then use on the other new command ...

Run Cron

The hg:run-cron command will execute an XF cron task - simply specify a cron ID as the argument.

For example: cmd.php hg:run-cron activitySummaryEmail will run the "Send activity summary email" cron task.

By default, disabled cron tasks cannot be run - so you can override this by specifying the -f or --force option on the command line.

The same verbosity flags work here - so specify -v, -vv or -vvv to generate the desired level of output.

View attachment 3077