Support Tickets Imap (Cron Issue?)

[phireuk]

I'm back again

 

Im trying to get ticket email replys through to my support manager.  I presume as i'm using the IMAP option, the email piping threads don't apply to me, at least the documentaion suggests this.

 

In my department settings I have added an email and IMAP settings for an email i control;

(the root domain, but not my blesta subdomian) for exapmle

support@mydomain.com  

My blesta install is at  hosting.mydomain.com   I assume as IMAP settings don't not care what the domain is, so long as the settings are correct.  Is that right?

 

So assuming my settings are correct...  I use zoho for the email in question.

 

Email:           support@mydomain.com

Username:   support@mydomain.com

Pasword:      ***************

SSL (port)  993

Host (IMAP server)  imap.zoho.com

 

The settings work on a client.  so im sure it not a settings issue.

 

 

However cron never works, just the same since I started testing my support manager setup. 

 

 

The 5 min cron for download tickets has never ran, all other cron tasks are fine, but this just keeps trying to run and the little animation keeps whirring around.

 

When i look in cron logs there is nothing there about support emails.

 

any ideas?

 

PS I have deleted all the database entries in cron_task ID 19 as per this thread

 

http://www.blesta.com/forums/index.php?/topic/4168-support-department-imap-not-working/?hl=imap%20support

 

But still not working.

[phireuk]

I also think mailparse "mailparse.so"

 

should be added in your php.ini file and next restart php, and restart apache

 

Well done sir! 

 

Looks like that has solved it

 

I added

extension=mailparse.so

to /etc/php5/cli/php.ini

 

in the extensions section, and rebooted. 

 

Big thanks to Tyson, Paul, Licensecart and Serge.

 

next time im not going to bother with a VPS and just install on a shared cpanel

[phireuk]

Tried with multple IMAP accounts,  still get the same issue.  POP doesn't work either.   Just end up with a NULL value in  end_date and cron fails.

 

 

 

 

Does anyone know a way to make blesta support work?   

 

Im using VestaCP which doesn't have an option for piping.  So does anyone have a solution to get support emails by any means?

[Tyson]

Usually when a cron task fails it's because 1) there was a fatal error that stopped execution, 2) the task timed out, or 3) the task is still running and is taking quite long.

 

If you haven't already, you may want to check the php logs for any errors that may have occurred during execution, such as running out of memory. You could also enable error reporting in Blesta, delete the cron task with a NULL end date, and run the cron manually from [settings] -> [system] -> [Automation] to see if any errors are encountered.

[Paul]

The most common issue here is missing mailparse, which is required to parse email for ticket creation.

 

If mailparse is not installed, you can usually install it with: pecl install mailparse

 

See http://wiki.cerbweb.com/Installing_PHP_Mailparse for more details on installing mailparse.

[serge]

I would like to recommend you to check at your firewall parameter if you allowed your IMAP port(s),

 

By the way if you have a firewall, what is it?

[phireuk]

If i delete the NULL valure and run Cron manually I get;

 

Attempting to run all tasks for My company.
Attempting plugin cron for support_manager poll_tickets.
Finished plugin cron for support_manager poll_tickets.
All tasks have been completed.
Attempting to run all system tasks.
All system tasks have been completed.

 

 

And the email gets through into support manager.

 

But then...  Cron runs the next time automatiaclly and the same issue with NULL value. 

 

No errors, can't find any php error_log file

[phireuk]

I would like to recommend you to check at your firewall parameter if you allowed your IMAP port(s),

 

By the way if you have a firewall, what is it?

 

Fail2ban.   But the email gets through I just found out if running cron manually...  the next auto cron it creates a NULL value in end date and never completes so all future emails don't get through.

 

ACCEPT TCP / IMAP 143,993 0.0.0.0/0

[Paul]

If it works when you run it manually, but not via the cron, then I would venture to guess that your CLI environment is different.. it may be missing mailparse.

 

Do you have SSH access? If so, try disabling your cron temporarily, wait 5 minutes, and run it via CLI just as your cron would. Does it hang? If so, clear the hang and try again after enabling error reporting in your /config/blesta.php config file

 

To enable error reporting, edit /config/blesta.php and change

 

Configure::errorReporting(0);

 

to

 

Configure::errorReporting(-1);

[phireuk]

 

If it works when you run it manually, but not via the cron, then I would venture to guess that your CLI environment is different.. it may be missing mailparse.

 

Do you have SSH access? If so, try disabling your cron temporarily, wait 5 minutes, and run it via CLI just as your cron would. Does it hang? If so, clear the hang and try again after enabling error reporting in your /config/blesta.php config file

 

To enable error reporting, edit /config/blesta.php and change

 

Configure::errorReporting(0);

 

to

 

Configure::errorReporting(-1);

 

 

Thanks for the advice.  I double checked mailparse and, added a test.php page, outputs the following.

 

phpinfo()  says

 

mailparse mailparse support enabled Extension Version 2.1.6 Revision $Revision: 305002 $

Directive Local Value Master Value mailparse.def_charset us-ascii us-ascii

 

 

If I run cron manually twice in a row,  the second time, it doesn't run the poll_tickets

 

1st

Attempting to run all tasks for My company.

Attempting plugin cron for support_manager poll_tickets.

Finished plugin cron for support_manager poll_tickets.

All tasks have been completed.

Attempting to run all system tasks.

All system tasks have been completed.

 

2nd

Attempting to run all tasks for My company.

All tasks have been completed.

Attempting to run all system tasks.

All system tasks have been completed.

 

 

EDIT:

As for running cron from putty, I have no idea where to begin, never done that before. error reporting in blesta is at -1 already.  and this may be a daft question be where would the results get stored?  In a php error log or in the database somewhre?

 

 

I am unable to get email messages running manually now, I can't replicate what I did to get that 1 email through. 

 

EDIT2:

 

The department email setting is set to "Read"  the email however the 1 email that got through shows in the zoho inbox as unread.  Not sure if that relevant or not. 

[phireuk]

OK so..  this is what I have discovered

 

Running Cron manually, only pulls the email through if there are 0 entries in the log_cron table in the field run_id with the value 19.  (NULL or otherwise)

 

IE, the email will only arrive if I;

1. DELETE FROM `admin_blesta`.`log_cron` WHERE `log_cron`.`run_id` = 19

2. reply to the customer with ticket assigned to a staff member

3. reply via email as the customer

4. run cron manually

 

Then and only then does the email come through.  The next time cron runs automatically i get a NULL value again.

[phireuk]

More informtion on what happens. 

 

If I delete all log_cron` WHERE `log_cron`.`run_id` = 19

and leave cron to run as normal...

then...

Blesta does read my inbox, (unread emails show as read) but the email does not show in support manager,  this rules out a firewall issue. 

 

Im 99% sure this is a blesta problem and not something I have done or a setup problem.

[Tyson]

Running Cron manually, only pulls the email through if there are 0 entries in the log_cron table in the field run_id with the value 19.  (NULL or otherwise)

 

This is normal behavior. The cron only runs tasks that are ready to be run based on their run time or interval. For example, if you run the cron right now, and then again in 1 minute, no cron tasks will actually run the second time because the minimum interval is 5 minutes and that time has not yet elapsed since the task was last run.

 

Additionally, if the cron task has a null end date, it is considered to be still running, and the cron task cannot be run again while it is still running. In case it errors out or stalls (as in your case), it will automatically be stopped after 6 hours.

 

However, since you are testing and debugging this cron task, it would be necessary to clear recent log entries from the database in order to run the task again. It's important to note, though, that deleting cron logs for some tasks may have detrimental effects, such as causing duplicate invoicing to be done for the same service.

 

 

If I delete all log_cron` WHERE `log_cron`.`run_id` = 19

and leave cron to run as normal...

then...

Blesta does read my inbox, (unread emails show as read) but the email does not show in support manager,  this rules out a firewall issue.

 

It sounds like there may be an issue with SwiftMailer working in CLI mode. Is there a different php.ini being used for CLI mode on the web server? A lower memory configuration may cause a memory allocation error at run time, which could lead to this issue. Taking a look at the php error logs would help. A log file should exist on the filesystem whether or not there are errors.

[phireuk]

Thanks for the heads up, and advice.  Honestly, I can't find a php error log.  but fortunatly, vestaCP has a cron log, which repoted this...

 

 

Attempting to run all tasks for My Company Limited.
Attempting to apply credits to open invoices.
There are no invoices to which credits may be applied.
The apply credits task has completed.
Attempting to deliver invoices scheduled for delivery.
No invoices are scheduled to be delivered.
The deliver invoices task has completed.
Attempting to provision paid pending services.
The paid pending services task has completed.
Attempting to unsuspend paid suspended services.
The unsuspend services task has completed.
Attempting to process renewing services.
The process renewing services task has completed.
Attempting plugin cron for order accept_paid_orders.
Finished plugin cron for order accept_paid_orders.
Attempting plugin cron for support_manager poll_tickets.
PHP Fatal error: Call to undefined function mailparse_msg_create() in /home/admin/web/mydomain.com/public_html/plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php on line 130
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us" lang="en-us" dir="ltr">
    <head>
        <title>Blesta</title>
        <link rel="stylesheet" type="text/css" href="/app/views/errors/css/styles.css" />
        <meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
    </head>

    <body>
            <div class="program_error">
        <h3>Oh noes!</h3>
        <div class="contents">
            <p>Call to undefined function mailparse_msg_create() on line <strong>130</strong> in <strong>/home/admin/web/mydomain.com/public_html/plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php</strong></p>
        </div>
    </div>    </body>
</html>

 

 

 

iv'e not looked in the file at line 130, because, to be honest, im not sure what i would be looking for.  As Paul mentioned it could be something to do with mailparse, but php info says it's enabled.

 

For the record,  it's hosted on a KVM, my memory never has less than 200 MB free and 950MB free swap.

 

Any ideas?

 

 

EDIT:

  /**
   * Set the email text
   * @return Object MimeMailParser Instance
   * @param $data String
   */
  public function setText($data)
  {
    $this->resource = mailparse_msg_create();
    // does not parse incrementally, fast memory hog might explode
    mailparse_msg_parse($this->resource, $data);
    $this->data = $data;
    $this->parse();
    return $this;
  }

[Michael]

have you got the pecl or something version of mailparse?

[phireuk]

have you got the pecl or something version of mailparse?

 

Not sure, to be honest!  what version do i need?  This is what php is reporting...

 

 

here is the only other mention of mailparse

 

[Michael]

That's the PHP, Mailparse uses that and Percl or pecl or perl or something weird. 

[phireuk]

That's the PHP, Mailparse uses that and Percl or pecl or perl or something weird. 

 

This is how i installed it.      as root...

apt-get install php5-gd php5-imap php-pear php5-dev make

pecl install mailparse

vim /etc/php5/apache2/conf.d/mailparse.ini

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;added this one and only line;;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
extension=mailparse.so

----------------------
saveded it and exited

service apache2 restart

I used this guide

http://wiki.cerbweb.com/Installing_PHP_Mailparse_Ubuntu

 

Did i do something wrong?

[Michael]

nope looks good.

[phireuk]

nope looks good.

 

hmmm, I guess, i just need to wait for US west cost to have their corn flakes.  Then hopefully one of the devs can she some light on;

 

PHP Fatal error: Call to undefined function mailparse_msg_create() in /home/admin/web/mydomain.com/public_html/plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php on line 130

[serge]

I saw you installed some packages, and restarted apache, but I think you should restart php, and next restart apache

[Michael]

hmmm, I guess, i just need to wait for US west cost to have their corn flakes.  Then hopefully one of the devs can she some light on;

 

PHP Fatal error: Call to undefined function mailparse_msg_create() in /home/admin/web/mydomain.com/public_html/plugins/support_manager/vendors/mime_mail_parser/MimeMailParser.class.php on line 130

 

Are you using CloudLinux?

[serge]

I also think mailparse "mailparse.so"

 

should be added in your php.ini file and next restart php, and restart apache

[Michael]

Well done sir! 

 

Looks like that has solved it

 

I added

extension=mailparse.so

to /etc/php5/cli/php.ini

 

in the extensions section, and rebooted. 

 

Big thanks to Tyson, Paul, Licensecart and Serge.

 

next time im not going to bother with a VPS and just install on a shared cpanel

 

dam it stupid file ext's lol and if you use a commercial panel or just plan Ubuntu or Centos you wouldn't have issues  

[serge]

Good you got it working.

 

I think you are using debian or ubuntu, and debian is the OS on my servers, I tried cpanel and webmin/usermin, and found webmin is very better & robust, there is even a bootstrap theme so it's look fine.

 

But nevermind if you have a control panel, I found that in generall for things related to php or webserver config, it's very better to use command line than use feature in the panel.  and regading php config & debian OS, I found the only files that really matter to check are:

- /etc/php5/cli/php.ini

-/etc/php5/fpm/php.ini

-/etc/php5/cgi/php.ini