Cronjobs

Description

MPOS is using various cronjobs to do back end processing. This includes but is not limited to:

• Finding new blocks created by the pool
• Updating block confirmations in the pool
• Counting round boundaries
• Processing user round/share payouts and debit transactions (manual and automatic)
• Processing worker notifications
• Updating statistical data used by the frontend
• Cleanup of archived shares
• Other smaller tasks that needs to be handled by the backend

Logging

All crons have logging to console disabled. Instead, a logfile is created for each cron under the logs directory in MPOS. If you are having issues with crons (you can see their status on the Admin Panel -> Monitoring page) this is the best place to check for additional information. If you wish to enabled debug mode, modify shared.inc.php and replace KLogger::INFO with KLogger::DEBUG. Ensure to disable this option again when you are done, logfile will grow rather large with it enabled!

Log Rotation

A logrotate example file is included in the repository at cronjobs/etc/logrotate.conf and can be triggered with the cronjobs/logrotate.sh script. It will cycle the files at a daily interval keeping up to 7 days as an archive.

Cronjobs

A brief description of all the cronjobs included in this project, sorted alphabetically.

archive_cleanup.php

Scans the shares_archive table for old shares that can be deleted according to the configuration. You can modify the cleanup behavior in the global config.

payouts.php

Runs all scheduled payouts setup or initiated by users. Each user will be processed independently so even if a user has setup a wrong LTC address (even though MPOS will try to ensure it's valid), other users are not affected by that. Disabling this payout via Admin Panel will allow for some maintenance work without payouts being processed.

blockupdate.php

Checks our RPC service for updated confirmation records for our found blocks and transfers them to the DB. Without this, no transactions would be confirmed and converted to confirmed credits.

findblock.php

As the name suggest, it will look into the RPC service for newly found blocks and add them to the database. Once all blocks are found, it will check each blocks upstream accepted share and calculate the round shares. No further processing is done, but this information will be used by the payout crons later.

notifications.php

As the name suggestes, notifications related to backend jobs like IDLE workers will be sent with this cronjob. It will also ensure that notifications are reset once a worker becomes active again so new notifications can be send out. You can globally disable notifications but each user also has the ability to setup their notifications. Globally disabled notifications override all user setting.

pplns_payout.php & proportional_payout.php & pps_payout.php

These crons, depending on which one is enabled in the global configuration, will handle payouts to users. PPLNS and Prop both are round based while PPS will payout per share. Round ends are still processed for statistical purposes. Only unaccounted new blocks with a valid share ID will be processed!

statistics.php

Updates various cache keys in memcache to allow the frontend to respond fast to requests. Most notably it is checking for all users shares and increments them each run so this information is available to the frontend without checking the database.

tickerupdate.php

Runs API calls against external sites. Since we can't cross-call APIs due to XSS protection in browsers, this cron will check them instead. Results are added to the database and made available to the frontend.

tables_cleanup.php

Runs a few maintenance tasks to keep your tables clear.

Setup

Instead of running a single cronjob manually it is recommended to use a split automatic setup to ensure some crons are always running at set intervals, specifically our statistics.php. For long rounds or coins with a lot of shares, it is a requirement to run the statistics cron as often as possible to ensure a responsive site after a round ends.

run-statistics.sh

This cron will ONLY update the statistics cache. You can add it to your crontab at a minutely interval.

run-payout.sh

Manages the round ends, finding blocks and everything related to internal and external payouts. Can run as often as you need, for PPS pools it is recommend once per 30 minutes to one hour. This keeps the amount of transactions created as low as possible, enabling faster payout for users.

run-maintenance.sh

Clears up your tables, sends IDLE worker notifications and updates the coin price and uptime robot status. Can be run as often as needed, but once every minute should be fine.

Sample configuration

This is a sample configuration for a pool. It will disable mailing events through cron and ensure that we are not running into cron-conflicts between multiple MPOS instances by adding the subfolder parameter -d. Other coins can be called the same way by adding other subfolders where to store the PID files (usually /tmp/<FOLDER>/*.pid). To make your own MPOS configuration run your crontab by calling crontab -e and pasting the cronjob data you create generateit.net and crontab-generator.org at the end of the created file. Once your file is created and saved, you can view your crontab by calling it with the crontab -l command.

Example crontab:

MAILTO=""
* * * * * /var/www/MPOS/cronjobs/run-statistics.sh -d LTC
* * * * * /var/www/MPOS/cronjobs/run-payout.sh -d LTC
* * * * * /var/www/MPOS/cronjobs/run-maintenance.sh -d LTC

(Below applicable for development branch) If the cron stuck for some reasons and didn't end properly (i.e., unexpected shutdown of the process), the database remains marked as the cron is active so the same job will not run in its next execution. In this case you will need to run the cron manually with -f option to ignore the active flag and make it finish properly. This is for the system safety.

If you are lazy you can use -t option to ignore the active flag created before than the time (in second) you specified to re-run it over the stale job. For example, -t 3600 ignores the active flag before than one hour. However, you should use this with extreme caucion. It is basically a force cron with a timeout so you may miss the opportunity of manual intervention for database/wallet inconsistency. ⚠️There's possibility of double payment if you use the flag for run-payout or run-maintenance. Please use it with accepting the risk and don't use if you don't understand what you do.