Hi guys, I’m starting this thread to hopefully shed a light on the obnoxious problem of cron management in FreePBX.
The main consequence that most of the users notice is the tls certificate expiring because the relative cron entry gets removed, but this is just the peak of the iceberg! I’m monitoring the issue for more than a year now and I’ve pretty clear in my mind what is going on (I had it clear years ago already, oh well…)
First a little summary of some discussions regarding this issue:
And now a brief description with identified cause and proposed solution:
FreePBX switched to a unified Job interface in v.14 to manage recurring task with the objective of avoiding issues with modules directly editing the system crontab and messing with it. And that’s great!
The Job class works really well but does not implement (yet, my fault I didn’t have the time to continue the PR) a parallel system to handle multiple “jobs” coming in, so it is not suitable for intensive tasks that will block subsequent calls until completed.
Now it’s all fine and dandy until we reach modules that still uses cron to handle their recurring tasks! I encountered two for now: one is fwconsole itself, and one is certmanager. Following is the content of the crontab when not purged (on my system)
*/15 * * * * [ -e /usr/sbin/fwconsole ] && sleep $((RANDOM\%30)) && /usr/sbin/fwconsole userman --syncall -q
8 3 * * * /usr/sbin/fwconsole certificates --updateall -q 2>&1 >/dev/null
* 5 * * * /usr/sbin/fwconsole util cleanplaybackcache -q
36 0 * * 1 [ -e /usr/sbin/fwconsole ] && /usr/sbin/fwconsole ma listonline --sendemail -q > /dev/null 2>&1
36 1 * * 1 [ -e /usr/sbin/fwconsole ] && /usr/sbin/fwconsole sys listonline --sendemail -q > /dev/null 2>&1
* * * * * [ -e /usr/sbin/fwconsole ] && sleep $((RANDOM\%30)) && /usr/sbin/fwconsole job --run --quiet 2>&1 > /dev/null
This is a pretty consistent crontab, but on FPBX versions > 14 should only contain one line (the last one)! This because all the recurring tasks should have been migrated to the Job class, but evidently the switch have never been completed.
Now as pointed out multiple times this would be a non-issue if the crontab was left untouched, but instead it gets periodically purged (found the suspect here! FBI there’s no need to thank me 
).
From my experience the update checks continue to work even if it gets purged (why? no clue. Maybe it is periodically brought back and then purged again) but certman does not restore its crontab, at least not that often and this causes the expiration of certificates, the first thing users notice. Now, I saw people saying that they never encountered the issue, but this seems impossible to me! The code to purge the crontab is here and certman cannot update in any other way (see certman code for cron entry).
Now, would I suggest removing the code to purge the crontab from Job class? Absolutely not! I think the concept is great, but we should pursue it till the end, finishing what we started.
So, what are the next steps?
- I’m gonna release a module that uses the Job class to update the certificates. This is only a workaround, meant as a temporary fix
- Create a new PR for Job to allow for background/parallel execution of jobs
- Migrate all existing modules that still use the old cron entries to use the “new” Job class
- Completely deprecate the old cron calls in BMO, to avoid the rise of new issues like this one
I hope it is all clear and hope that somebody will jump in to help us improving FreePBX for every one, in the meantime
Thank you!