Cron Error Help

[multibyte]

Hello everyone,

 

Really hoping someone can help as this is driving my crazy 

 

I am facing problems with the "deliver invoices" cron. The circular diagram has been spinning round now for the past 24 hours with no option to stop it. 

 

I tried changing the cron to /local/ in cpanel but this has made no difference ( Other Crons are working as normal)

 

This is a brand new installation of Blesta with just one test account and the tested invoice which has not sent. 

 

I can not re-install Blesta as we are working on custom look and feel which is taking up alot of my time.

 

Also the logs for Cron are not showing any information regarding this either.

 

The invoice can also not be downloaded, but strangely the reminder emails for it are sending as normal. 

 

I really hope someone can help 

 

Thanks 

[Michael]

It's stuck so you need wait to un lock it.

[multibyte]

It's stuck so you need wait to un lock it.

 

Thanks Licensecart how long does this take as I have now been waiting 30 hours?

[Michael]

Thanks Licensecart how long does this take as I have now been waiting 30 hours?

 

It depends, I think you might be able to force it via the database but I'm not 100% so I wouldn't recommend it.

 

http://www.blesta.com/forums/index.php?/topic/1052-system-status-there-are-one-or-more-cron-tasks-that-have-been-executing-for-more-than-60-minutes/#entry8567

[multibyte]

Very Strange I have managed to get the Invoices to work however the Provision of Paid Services is now playing up. 

 

It creates the account (see pictures) but the cron is sticking.

 

However I can login to the account Via Cpanel

 

Any advise? 

[Michael]

Sounds like cPanel isn't calling home to Blesta that it's been provisioned. 

[multibyte]

Sounds like cPanel isn't calling home to Blesta that it's been provisioned. 

 

Any ideas how to fix this?

[Michael]

Any ideas how to fix this?

 

I don't sorry I don't use cPanel.

[serge]

check your firewall to see if it's allow port used by cpanel, from memory 2083,2087, 2086,....(check it in cpanel doc)

 

but I'm no more using cpanel, I moved to webmin, very best in my opinion

[Tyson]

It sounds something is causing the cron to error out. You should enable error reporting in Blesta and run the cron manually. Note that cron tasks run at specific times/intervals. If a task fails (shows the spinning icon), it may wait 6 hours to try running again.

 

If you're familiar with databases/SQL, you can update the `log_cron` table and delete all records that have a NULL `end_date`. You should be very careful with deleting the `log_cron` records if you are using Blesta in a live environment. Deleting the records entirely lets Blesta know that those tasks were not run, and so it will attempt to run those tasks again when the cron runs next. It would be best to immediately run the cron manually (don't let it run automatically) at this point so that you can view the output of each task as it is run. With error reporting enabled, any errors encountered should appear on the [system] -> [Automation] page. Once you know what the errors are, we can determine the issue and offer a remedy.

 

If you're not familiar with databases/SQL, then you can disable the cron from running automatically instead. Then wait a while (wouldn't need to be more than 6 hours) so that you can run the cron manually. All of the problematic tasks would run, and any errors encountered will be displayed from the [system] -> [Automation] page.

[multibyte]

It sounds something is causing the cron to error out. You should enable error reporting in Blesta and run the cron manually. Note that cron tasks run at specific times/intervals. If a task fails (shows the spinning icon), it may wait 6 hours to try running again.

 

If you're familiar with databases/SQL, you can update the `log_cron` table and delete all records that have a NULL `end_date`. You should be very careful with deleting the `log_cron` records if you are using Blesta in a live environment. Deleting the records entirely lets Blesta know that those tasks were not run, and so it will attempt to run those tasks again when the cron runs next. It would be best to immediately run the cron manually (don't let it run automatically) at this point so that you can view the output of each task as it is run. With error reporting enabled, any errors encountered should appear on the [system] -> [Automation] page. Once you know what the errors are, we can determine the issue and offer a remedy.

 

If you're not familiar with databases/SQL, then you can disable the cron from running automatically instead. Then wait a while (wouldn't need to be more than 6 hours) so that you can run the cron manually. All of the problematic tasks would run, and any errors encountered will be displayed from the [system] -> [Automation] page.

 

Hello Tyson, I have done as you have asked but were do I find the error report after enabling it?

 

Thanks 

[multibyte]

Have also deleted all queries with Null Value as requested run the cron manually and added a new service which I am waiting for it to provision 

[Tyson]

How did you run the cron manually? By running it manually, I was referring to clicking the "Run Cron Manually" button on the [settings] -> [system] -> [Automation] page in Blesta. Once you click to run the cron, a box will appear that lists logging info for each task that is being run. If one of the tasks leads to an error, the error itself will be shown in that box since you enabled error reporting.

[multibyte]

Hello Tyson, I turned on error reporting, then went to mysql and deleted the NULL values. I then ran the crons manually (~the way you have stated) which worked no problem.

I then tried to add a service for my test account which went threw ok as the same in the first post but now caused the Provision of paid services to freeze again.

 

Hope this helps

[Michael]

Hello Tyson, I turned on error reporting, then went to mysql and deleted the NULL values. I then ran the crons manually (~the way you have stated) which worked no problem.

I then tried to add a service for my test account which went threw ok as the same in the first post but now caused the Provision of paid services to freeze again.

 

Hope this helps

 

if the service has been provisioned on cPanel it won't activate with the cron again because it will error out.

[multibyte]

if the service has been provisioned on cPanel it won't activate with the cron again because it will error out.

Hello licencecart i didn't explain clearly after deleting the nul entries i also deleted the pervious hosting signup then after running the cron manually i signed up for a brand new hosting package.

Thanks

[multibyte]

Does anybody have any ideas what this could be please?

 

Thanks

[Tyson]

Hello Tyson, I turned on error reporting, then went to mysql and deleted the NULL values. I then ran the crons manually (~the way you have stated) which worked no problem.

I then tried to add a service for my test account which went threw ok as the same in the first post but now caused the Provision of paid services to freeze again.

 

Hope this helps

 

I'm a little confused. You said you ran the cron manually and didn't have an issue. Then you created a service and ran the cron again to find that the Provision of Paid Pending services froze?

 

I would test it like this:

1. Enable error reporting (you already did this)
2. Disable the cron from running automatically
3. Clear the frozen cron tasks as you did earlier, by removing all `log_cron` records that have a NULL `end_date`.
4. Create a test service in Pending status. Pay the invoice associated with it if you created one. This will now be a 'paid pending service' that the cron will attempt to provision automatically.
5. Run the cron manually so that it will attempt to provision the service.
6. Look at the output of the cron from the Automation page in Blesta. Note any errors

If you don't see an error, and the task froze again, then you should see this in the output:

Attempting to provision paid pending services.

...but afterward, you should not see:

The paid pending services task has completed.

This would indicate the task is either 1) still running, or 2) failed but did not generate an error. You should check the module logs under [Tools] -> [Logs] to see if there is any output for the attempt to provision the service. You can click the top table row to show a list of Input/Output. It would be useful to see what (if anything) is available here as well.

[multibyte]

I'm a little confused. You said you ran the cron manually and didn't have an issue. Then you created a service and ran the cron again to find that the Provision of Paid Pending services froze?

 

I would test it like this:

1. Enable error reporting (you already did this)
2. Disable the cron from running automatically
3. Clear the frozen cron tasks as you did earlier, by removing all `log_cron` records that have a NULL `end_date`.
4. Create a test service in Pending status. Pay the invoice associated with it if you created one. This will now be a 'paid pending service' that the cron will attempt to provision automatically.
5. Run the cron manually so that it will attempt to provision the service.
6. Look at the output of the cron from the Automation page in Blesta. Note any errors

If you don't see an error, and the task froze again, then you should see this in the output:

Attempting to provision paid pending services.

...but afterward, you should not see:

The paid pending services task has completed.

This would indicate the task is either 1) still running, or 2) failed but did not generate an error. You should check the module logs under [Tools] -> [Logs] to see if there is any output for the attempt to provision the service. You can click the top table row to show a list of Input/Output. It would be useful to see what (if anything) is available here as well.

 

Hello Tyson, I have completed the above as requested please see below. ]

 

I created a test service and ran manually but it froze saying..  Attempting to provision paid pending services

 

However as stated the cpanel log shows it as being successfully created and I can confirm the account was created on WHM. 

 

Hope this helps.

[Tyson]

Since there is no error displayed, and the account was created in WHM, I suspect there is a communication problem between cPanel and the server Blesta is installed on. It doesn't appear that Blesta is receiving a response from cPanel that indicates the WHM account was actually created. Have you checked your firewall settings to see if any incoming requests are being blocked?

[multibyte]

Hello Tyson, 

 

Have just been checking over the system and noticed the following error (picture attached) hope this helps.

 

Also with reference to the firewall is there a tutorial on how to do this at all?

 

Thanks for all of your help!

 

[Tyson]

The cron log you included shows the service could not be processed with the module. Looks like it didn't cause the cron to stall at least, which is a plus. however, you should check the module logs under [Logs] -> [Module] to see if there is any more detailed error on why it failed to provision the service.

 

Firewall settings/logs should be available to the server admin. Tutorials and documentation would be based on the firewall, OS, etc., and I don't know enough about your system to give more insight. But since your cron didn't stall this time, there may be something more descriptive in the Module Log to check first.

[multibyte]

Hello,

I just tried to add the service via the admin panel and it shows the oh no! command below which I do not understand, thanks. 

 

Oh noes!

SQLSTATE[HY000]: General error: 2006 MySQL server has gone away on line 124 in /home/multihub/public_html/account/lib/model.php 

Printing Stack Trace:
#0 /home/multihub/public_html/account/lib/model.php(124): PDOStatement->execute(Array)
#1 /home/multihub/public_html/account/components/record/record.php(669): Model->query('SELECT COUNT(*)...', Array)
#2 /home/multihub/public_html/account/components/record/record.php(760): Record->fetch()
#3 /home/multihub/public_html/account/app/app_model.php(0): Record->numResults()
#4 [internal function]: AppModel->validateExists('1', 'id', 'modules')
#5 /home/multihub/public_html/account/components/input/input.php(478): call_user_func_array(Array, Array)
#6 /home/multihub/public_html/account/components/input/input.php(317): Input->validateRule('module_id', Array, '1', 'module_id')
#7 /home/multihub/public_html/account/app/models/logs.php(234): Input->validates(Array)
#8 /home/multihub/public_html/account/components/modules/module.php(779): Logs->addModule(Array)
#9 /home/multihub/public_html/account/components/modules/cpanel/cpanel.php(1562): Module->log('109.73.172.66', NULL, 'output', false)
#10 /home/multihub/public_html/account/components/modules/cpanel/cpanel.php(808): Cpanel->parseResponse(NULL)
#11 /home/multihub/public_html/account/app/models/services.php(817): Cpanel->addService(Object(stdClass), Array, NULL, NULL, 'active')
#12 /home/multihub/public_html/account/app/controllers/admin_clients.php(4301): Services->add(Array, Array, true)
#13 /home/multihub/public_html/account/app/controllers/admin_clients.php(4205): AdminClients->createService(Array, Array)
#14 /home/multihub/public_html/account/app/controllers/admin_clients.php(3640): AdminClients->processServiceStep('confirm', Object(stdClass), Object(stdClass), Object(stdClass))
#15 /home/multihub/public_html/account/lib/dispatcher.php(111): AdminClients->addService()
#16 /home/multihub/public_html/account/index.php(21): Dispatcher::dispatch('/account/admin/...')
#17 {main}

Fatal error: Uncaught exception 'PDOException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away' in /home/multihub/public_html/account/lib/model.php:124 Stack trace: #0 /home/multihub/public_html/account/lib/model.php(124): PDOStatement->execute(Array) #1 /home/multihub/public_html/account/components/record/record.php(225): Model->query('INSERT INTO `se...', Array) #2 /home/multihub/public_html/account/components/session/session.php(272): Record->insert('sessions', Array) #3 [internal function]: Session->sessionWrite('8beb7a13b5ce293...', 'blesta_company_...') #4 /home/multihub/public_html/account/components/session/session.php(47): session_write_close() #5 [internal function]: Session->__destruct() #6 {main} thrown in /home/multihub/public_html/account/lib/model.phpon line 124

 

 

[Michael]

Your MySQL is timing out you need to up the mysql value for it or move a provider if you can't.

[Paul]

The error indicates that MySQL crashed for some reason. Not necessarily a timeout or anything. Normally if MySQL crashes, it's a MySQL issue.