Getting Useful Log Information From Blesta

[Virtovo]

I'm constantly running into issues with Blesta and it's hard to tell if it is an issue that we are causing or is a fault with Blesta.  The biggest issue is that Blesta doesn't provide decent logging of its actions.

 

I've currently got an issue where tickets are not important to a certain department from POP3.  Tickets import fine to other departments and the cron tells me it has completed successfully.  The Task int he automation section tells me that the task last run recently yet the emails are not imported.  I've checked the details for the department and all appears well (copying the details out into a different application works fine).

 

Does anyone know how to get meaningful logs out of Blesta of what is actually going on?  Piping the cron output is a waste of time as it just tells me the cron completed successfully with no specifics. 

[Max]

Does anyone know how to get meaningful logs out of Blesta of what is actually going on?  Piping the cron output is a waste of time as it just tells me the cron completed successfully with no specifics. 

 

Try modifying the code that suppresses errors in ticket_manager.php

catch (Exception $e) {
                // Ignore errors, continue on to the next department
            }

catch (Exception $e) {
                echo "Error processing e-mail: ".$e->getMessage()."\n";
            }

[Virtovo]

 

Try modifying the code that suppresses errors in ticket_manager.php

catch (Exception $e) {
                // Ignore errors, continue on to the next department
            }

catch (Exception $e) {
                echo "Error processing e-mail: ".$e->getMessage()."\n";
            }

 

 

Thanks, although I only get: Attempting plugin cron for support_manager poll_tickets. Finished plugin cron for support_manager poll_tickets.

 

In the cron log.

[Cody]

Blesta can't log everything it does, but it would certainly be nice to have an option that may be temporarily enabled to provide additional logging. This has already been discussed numerous times, and our answer is still the same. We can't provide verbose logging until we can make PHP 5.3 the minimum requirement for Blesta.

 

With that said, however, if there is something in particular you'd like help debugging we can certainly walk you through that.

[Virtovo]

Blesta can't log everything it does, but it would certainly be nice to have an option that may be temporarily enabled to provide additional logging. This has already been discussed numerous times, and our answer is still the same. We can't provide verbose logging until we can make PHP 5.3 the minimum requirement for Blesta.

 

With that said, however, if there is something in particular you'd like help debugging we can certainly walk you through that.

 

I need to know exactly what is happening when the support managing pulls tickets from the POP3 server.

[velaware]

I need to know exactly what is happening when the support managing pulls tickets from the POP3 server.

If you want me to help you on this feel free to shoot me an email.

[velaware]

Blesta can't log everything it does, but it would certainly be nice to have an option that may be temporarily enabled to provide additional logging. This has already been discussed numerous times, and our answer is still the same. We can't provide verbose logging until we can make PHP 5.3 the minimum requirement for Blesta.

 

With that said, however, if there is something in particular you'd like help debugging we can certainly walk you through that.

My question is what makes 5.3 special for this?  I'm not familiar w/ the changes, but if its a function you could just do

if(function_exists('some_func')){
    .. verbose logging stuff ...
}

[Cody]

I need to know exactly what is happening when the support managing pulls tickets from the POP3 server.

 

In /plugins/support_manager/components/ticket_manager/ticket_manager.php

 

This will tell you if an errors were thrown when connecting to or reading from the mail server.

 

From:

			}
			catch (Exception $e) {
				// Ignore errors, continue on to the next department
			}

 

To:

			}
			catch (Exception $e) {
				echo $e->getMessage();
				echo $e->getTraceAsString();
				die;
			}

This will tell you if any messages were found on the mail server.

 

From:

 

				foreach ($mailbox->searchMailbox($search_type) as $mail_id) {
					$email = new MimeMailParser();

 

To:

				foreach ($mailbox->searchMailbox($search_type) as $mail_id) {
					echo "\nfound message ID: " . $mail_id . "\n";
					$email = new MimeMailParser();

[Cody]

Also, you MUST run the cron manually in order to see the output from these modifications.

[Virtovo]

Nothing came out of that; however I've checked some logs that I have been keeping from the cron running.

 

The only thing that shows up intermittently is the following:

 

Error processing e-mail: SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null

[Virtovo]

Actually a second run of it led to:

 

found message ID: 1 SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null#0 /var/www/html/lib/model.php(124): PDOStatement->execute(Array) #1 /var/www/html/components/record/record.php(216): Model->query('INSERT INTO `su...', Array) #2 /var/www/html/plugins/support_manager/models/support_manager_tickets.php(243): Record->insert('support_attachm...', Array, Array) #3 /var/www/html/plugins/support_manager/components/ticket_manager/ticket_manager.php(202): SupportManagerTickets->addReply('34', Array, Array) #4 /var/www/html/plugins/support_manager/components/ticket_manager/ticket_manager.php(92): TicketManager->processTicketFromEmail(Object(MimeMailParser), Object(stdClass)) #5 /var/www/html/plugins/support_manager/support_manager_plugin.php(699): TicketManager->processDepartmentEmails() #6 /var/www/html/app/controllers/cron.php(1756): SupportManagerPlugin->cron('poll_tickets') #7 [internal function]: Cron->pluginTasks('72b7e890f3388c9...') #8 /var/www/html/app/controllers/cron.php(132): call_user_func_array(Array, Array) #9 /var/www/html/app/controllers/cron.php(94): Cron->all('72b7e890f3388c9...') #10 /var/www/html/lib/dispatcher.php(121): Cron->index() #11 /var/www/html/index.php(21): Dispatcher::dispatch('/cron/?cron_key...') #12 {main}

[Cody]

Doesn't look like you have error reporting enabled. But this sounds like it might be related to CORE-1077.

 

If you have the email headers feel free to PM me or submit a ticket and we can confirm.

 

The fix for CORE-1077 is the following change in /plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php

 

From:

      if (in_array($disposition, $dispositions))

To:

      if (in_array($disposition, $dispositions) && isset($part['disposition-filename']))

[Virtovo]

 

Doesn't look like you have error reporting enabled. But this sounds like it might be related to CORE-1077.

 

If you have the email headers feel free to PM me or submit a ticket and we can confirm.

 

The fix for CORE-1077 is the following change in /plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php

 

From:

      if (in_array($disposition, $dispositions))

To:

      if (in_array($disposition, $dispositions) && isset($part['disposition-filename']))

 

I'd love to try and implement this fix; however I've currently got POP3 import getting stuck again with the message "There are one or more cron tasks that have been executing for more than 60 minutes."

[Virtovo]

Applied the fix, enabled error reporting within Blesta and receive the following:

 

Attempting plugin cron for support_manager poll_tickets.
found message ID: 1 SQLSTATE[23000]: Integrity constraint violation: 1048 Column 'name' cannot be null#0 /var/www/html/lib/model.php(124): PDOStatement->execute(Array) #1 /var/www/html/components/record/record.php(216): Model->query('INSERT INTO `su...', Array) #2 /var/www/html/plugins/support_manager/models/support_manager_tickets.php(243): Record->insert('support_attachm...', Array, Array) #3 /var/www/html/plugins/support_manager/components/ticket_manager/ticket_manager.php(202): SupportManagerTickets->addReply('34', Array, Array) #4 /var/www/html/plugins/support_manager/components/ticket_manager/ticket_manager.php(92): TicketManager->processTicketFromEmail(Object(MimeMailParser), Object(stdClass)) #5 /var/www/html/plugins/support_manager/support_manager_plugin.php(699): TicketManager->processDepartmentEmails() #6 /var/www/html/app/controllers/cron.php(1756): SupportManagerPlugin->cron('poll_tickets') #7 [internal function]: Cron->pluginTasks('39ed9271381f3c2...') #8 /var/www/html/app/controllers/cron.php(132): call_user_func_array(Array, Array) #9 /var/www/html/app/controllers/cron.php(94): Cron->all('39ed9271381f3c2...') #10 /var/www/html/lib/dispatcher.php(121): Cron->index() #11 /var/www/html/index.php(21): Dispatcher::dispatch('/cron/?cron_key...') #12 {main}

 

And with that the task keeps running.  

[Cody]

What are the headers for message ID 1 in that mailbox?

[Cody]

To temporarily get around the issue you're experiencing you can edit /plugins/support_manager/components/email_parser/email_parser.php

 

From:

			$files['attachment']['name'][] = $attachment->getFilename();

To:

			$files['attachment']['name'][] = (($filename = $attachment->getFilename()) ? $filename : "unknown");

Since we're unable to duplicate the issue, we need a copy of the headers for the message that fails to parse correctly in order to debug.

[Virtovo]

In the interim I've deleted the messages in that mailbox just to get up and running.  I can update you with the headers when this happens again

[Cody]

In the interim I've deleted the messages in that mailbox just to get up and running.  I can update you with the headers when this happens again

 

Bummer. Well, if it does happen again please do capture the headers and send them along.