System Health and Updates says system cron tasks have not been ran but they have

This is the error I'm getting "The system cron does not appear to have completed successfully within the last 24 hours. Check your activity logs or learn more about enabling the cron in our documentation."

Any idea why? It looks like the cron completed.

Starting

Running Pre-Cron Hooks

Starting Generating Invoices

- 0 Invoices Created

Starting Applying Late Fees

- Late Invoice Fees added to 0 Invoices

Starting Processing Credit Card Charges

- Credit Card Payments Processed (0 Captured, 0 Failed)

Starting Processing Invoice Reminder Notices

- Sent 0 Reminders

Starting Processing Domain Renewal Notices

- Sent 0 Notices

Starting Processing Cancellation Requests

- Processed 0 Cancellations

Starting Processing Overdue Suspensions

- Processed 0 Suspensions

Starting Processing Overdue Terminations

- Processed 0 Terminations

Starting Performing Automated Fixed Term Service Terminations

- Processed 0 Terminations

Starting Auto Closing Inactive Tickets

Starting Processing Email Marketer Rules

Starting Updating Disk & Bandwidth Usage Stats

- Done

Starting Performing Client Status Sync

- Done

Completed

Cron Job Hooks Run...

Starting Database Backup

- Database backups are not configured.

Running After Cron Hooks

Goodbye

we had the same, am guessing it might be that the database back is not configg`d, have changed that now so will recheck tomorrow

Same problem and no error

Same here, db is getting backed up, no email is sent, it appears the system cron did run just no email sent and the System Health thinks it didn't run.

I am surprised more aren't reporting this or is it just that so many opted to not do the upgrade yet!? I was thinking about holding off until some bug reports flow in...but I got caught in a time warp!

Well I dumped the db and tried a fresh 6.1.0 installation/setup and the behavior is the same. Re read the docs to make sure, everything is set correctly, there must be a bug, WHMCS support declined to answer because I didn't put all the login info into the ticket, ergh! I don't want anyone logging into my systems unless it is really necessary. At any rate I can live with this bug for now as I know it is processing everything.

We had this error on the cron today after enabling backup of sql :-

Cron Job: An error occurred generating the backup archive. The error is: Unable to write tblmodulelog data.

We had this error on the cron today after enabling backup of sql :-

 

Cron Job: An error occurred generating the backup archive. The error is: Unable to write tblmodulelog data.

That sounds unrelated, however, make sure you have enough free disk space as it needs to be able to dump the db, you can test that manually as well make sure there are no other errors in your message log.

Same problem and no error

Same issue here. The cron ran and sent an email (as well as a db backup to the remote server) but it is saying it didn't run.

Same issue here. The cron ran and sent an email (as well as a db backup to the remote server) but it is saying it didn't run.

@Sliffer21 - Please clarify. Did the email come from your cron job only as in you did not >/dev/null it or is it the regular email that the cron.php produces? As of now I have not seen the regular email but if I take out the /dev/null or run it at the command line I get the report, so to speak. At this point in time WHMCS still has not answered my ticket, I believe this is due to them already understanding the bug and the fix is in the works. And also that it is really not detrimental since the job runs and does the work it needs to (at least I hope it is!!!).

@Sliffer21 - Please clarify. Did the email come from your cron job only as in you did not >/dev/null it or is it the regular email that the cron.php produces? As of now I have not seen the regular email but if I take out the /dev/null or run it at the command line I get the report, so to speak. At this point in time WHMCS still has not answered my ticket, I believe this is due to them already understanding the bug and the fix is in the works. And also that it is really not detrimental since the job runs and does the work it needs to (at least I hope it is!!!).

Hello,

The email sent is the one produced from WHMCS.

@Sliffer21 - What version of php, mysql are you on. I am on mysql 5.5.45, php 5.6.13. For me, the cron runs, producing the output and db backup, does not send the report and of course System Health says it hasn't run.

ps I just tried it with php 5.5 and the same results, plus System Health shows:

PHP Version

Your PHP version 5.5.29 is supported by WHMCS.

The PHP 5.5 branch no longer receives regular bug fixes and will only receive critical security updates until it reaches its end of life. We recommend updating to a supported PHP version. Please see http://php.net/supported-versions.php for more information.

We are running PHP 5.6.13 and MySQL 5.5.42

@Sliffer21 - try to send an email to a single client from whmcs admin. See if you don't get an error. Could not connect to SMTP host. I am getting this with PHP 5.6 but when I go back to 5.5 it goes away and the emails send. I checked the mail server logs and there were ssl errors. I changed to no encryption and port 587 / 25 and same error, only going back to php 5.5 seemed to do it. Just curious if that is your experience.

No issues at all on email. We had this issue a few weeks ago with Google Apps for Business and I went through trying SSL, TLS plain and just cycling through them back to SSL seemed to work but not sure why. If you use Google as a mail server provider (GMail or Google Apps for Business) sometimes it seems WHMCS and their servers will have issues talking. It happens every 6 months or so for us for just about an hour or so.

Ok, not using google for that, have own mailserver, but using self signed cert, signing it now just to see if that issue persists with phpmailer from what I have read I would have to go into the code in order to allow self signed and the call there would be encrypted by WHMCS, so let's see how the cert works.

- - - Updated - - -

@Sliffer21 - Have you raised a support ticket with WHMCS on this thread subject as well?

No, since so many people had this issue I assumed someone else I done so. I would be happy to if no one else has one? I have 3 pending support tickets right now on different issues from 6.0.2 and now some for 6.1.0. We have a purchase license of the Live Chat software that won't work WHMCS has given it a ID for tracking but only 2 people have the issue so they don't plan on fixing it any time soon I guess.

Getting the same message here: Your cron has not completed in the last 24 hours.

Running 6.1.0. Seems this is not correct. I don't use the e-mail piping but I assume all they should care for is the main cron.php

Same here, Cron job + pop3 ticket cron errors.

But both fine and working.

my ticket response:

I can advise that case #CORE-9170 is open with our developers in order to have this issue investigated for future releases. Unfortunately, I cannot provide an estimated time for completion for this. However, once we resolve cases and push features they are available at our change log.

Same issue here since upgrading to 6.1.0 - CRon runs and I get email saying so - and clients get their invoices/reminders ok, and I get my Database Backup ok - and logs show it complete - is just the health check not understanding the job is done

Also this message is "wrong":

Installed cURL Version

You currently have version 7.29.0 of cURL installed. This version is known to have security issues.

Redhat and any derivative that comes from RHEL (Centos / Scientific Linux / CloudLinux) backports and fixes bugs and vulnerabilities. https://access.redhat.com/security/updates/backporting/

Just checking the curl version it's wrong. It's updated and bugfree. Anyone can check it using rpm -q --changelog or grep just the CVEs involved:

[root@secure ~]# rpm -q --changelog curl | grep CVE

- fix connection re-use when using different log-in credentials (CVE-2014-0138)

- re-use of wrong HTTP NTLM connection in libcurl (CVE-2014-0015)

- fix heap-based buffer overflow in curl_easy_unescape() (CVE-2013-2174)

- fix cookie tailmatching to prevent cross-domain leakage (CVE-2013-1944)

- new upstream release (fixes CVE-2013-0249)

- new upstream release (fixes CVE-2012-0036)

- new upstream release (fixes CVE-2011-2192)

- update to 7.19.4 (fixes CVE-2009-0037)

 

 

Could this be due to the old crons getting ran and not the new ones?