Add -t option to ignore too old cronjob active flag

[mecab]

This PR adds -t TIME_IN_SEC option into the shell scripts for cronjobs.
Example usage: run-statistics.sh -t 3600

I have had some experiences that cronjob didn't finished properly (e.g., due to connection interruption of DB or coind) and ${cron_name}_active left 1. It causes keeping the job from running in next execution until I note it and manually remove the flag by running the job with -f option. The miners had inconvenience suchs as no credits added or no cash outs for a long time.

With this -t option, the jobs ignore the active flag if the last job was started before than the user specified by this option. For example, -t 3600 ignores the flag if it was started more than one hours ago. Note the option ignores PID file created by the shell script. By this option the cronjobs can automatically recovered from such a situation.

[TheSerapher]

What would ensure that on a fatal error without intervention and fixing that you won’t run into more issues?

Instead of working around a feature that potentially can save your pool from sending out coins that have been sent already due to wallet or whatever issues, establish a monitoring on the PID file by a monitoring system. It it gets too old, notify via mail or whatever that you have a stale Cron.

I don’t think this workaround, other than stopping you from checking your pools if something is funny, really adds a secure feature.

Just my 2 cents.

[mecab]

Yes, I agree it is a bit dangerous flag and basically pool op should fix stale crons with manual intervention. On the other hand this flag just allow them to have option to ignore trivial (well, I think what actually trivial is depends on the op's judge) errors with accepting risk.

The possibility of double payment of coins is a risk, but I think it could be accepted in some cases, such as small pools with friends or some kind of experimental pool. Also it could be useful for enabling the flag for specific less-dangerous task (i.e., enabling for run-statistics).

I totally agree that the situation should be resolved manually before the next worth thing happens but this option raises logWarn() so they could have chance to get noted by doing some handling of the log, adding to monitoring the PID file.

I know this PR is a bit controversial and I'm not intended to push you to merge. It's completely up to you. I just raised this PR just thinking someone perhaps need such a little workaround. 🙂

[TheSerapher]

Since I don't maintain this and can't judge what people want or need from it, I'll just merge it into development. Make sure it's documented somewhere with a big warning this can cause pool failure and double payouts and people need to accept this risk when using this option (basically a force cron with a timeout).

Thanks for the PR!

[mecab]

Oh, thank you for merging. I added some notes on cronjob wiki.