Incoming Email with G-Suite

Hello

I spent the most part of my day yesterday trying to setup incoming e-mail. I use GMail/Google Suite. To logon in GMail i use two-factor authentication. So I requested an app password for SuiteCRM. I run Nginx with php7.1-fpm and ssl on my server. My settings:

My nginx error log:


2017/11/13 07:44:34 [error] 998#998: *13304 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 84.193.91.61, server: maartenprovo.be, request: "POST /SuiteCRM/index.php?module=InboundEmail&to_pdf=1&action=Popup&target=Popup&target1=Popup&server_url=imap.gmail.com&email_user=maarten@maartenprovo.be&protocol=imap&port=993&email_password=xxxxxxxxxxxxxx&mailbox=INBOX&ssl=true&ie_id=&personal=false HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock", host: "www.maartenprovo.be", referrer: "https://www.maartenprovo.be/SuiteCRM/index.php?module=InboundEmail&action=EditView"

SuiteCRM log

What am I doing wrong?

You will find the debugging code in this thread useful:

https://suitecrm.com/forum/suitecrm-7-0-discussion/16507-mail-stopped-working-error-smtp-connect-failed

Then please come back and tell us what you found, I am interested in real-world difficulties configuring SuiteCRM email so we can try and get this right once and for all. Thanks.

I deleted the old and added the new code. But the output stays the same:

Nginx log


2017/11/13 16:58:17 [error] 998#998: *16601 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 84.193.91.61, server: maartenprovo.be, request: "POST /SuiteCRM/index.php?module=InboundEmail&to_pdf=1&action=Popup&target=Popup&target1=Popup&server_url=imap.gmail.com&email_user=maarten@maartenprovo.be&protocol=imap&port=993&email_password=pbwertqzzgjiaqkv&mailbox=INBOX&ssl=true&ie_id=&personal=false HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock", host: "www.maartenprovo.be", referrer: "https://www.maartenprovo.be/SuiteCRM/index.php?module=InboundEmail&action=EditView"
2017/11/13 16:58:33 [error] 998#998: *16601 upstream timed out (110: Connection timed out) while reading response header from upstream, client: 84.193.91.61, server: maartenprovo.be, request: "GET /SuiteCRM/index.php?module=Alerts&action=get&to_pdf=1 HTTP/2.0", upstream: "fastcgi://unix:/var/run/php/php7.1-fpm.sock", host: "www.maartenprovo.be", referrer: "https://www.maartenprovo.be/SuiteCRM/index.php?module=OutboundEmailAccounts&offset=1&stamp=1510587738060447800&return_module=OutboundEmailAccounts&action=EditView&record=1a5db685-a385-e176-aa89-59fac3207b2c"
2

SuiteCRM-log


Mon Nov 13 16:58:02 2017 [21565][-none-][FATAL] Configuration variable date.timezone is not set, guessed timezone Europe/Berlin. Please set date.timezone="Europe/Berlin" in php.ini!
Mon Nov 13 16:58:02 2017 [21565][1][FATAL] Job runs too frequently, throttled to protect the system.

Perhaps a stupid question, but does this really apply to this problem? SMTP works fine, I can send mails it’s the receiving that doesn’t work.

Regards

Ok, I thought your error was in Outbound, reading more carefully I see it’s inbound. Sorry.

You should solve the FATAL error before anything else. It means PHP has stopped executing, so it can break the app in all sorts of ways.

Try to figure out if that error is coming from the main app, or from the cron jobs. How often does it occur in the logs? Only when you access a page in SuiteCRM, or every minute?

Then try to get the date.timezone parameter configured correctly in php.ini.

Then tell me if that solves anything.

I fixed the timezone in the php.ini but I can’t get rid of the “Job runs too frequently, throttled to protect the system.”

I set all workflow tasks as well as the scheduled tasks in admin to inactive and it keeps on generating the error.

The error is indeed generated every minute.

I did install v7.9.7 which I now notice isn’t stable, is it better to downgrade to 7.8.8?

That “throttled” things basically means a job didn’t run, because it was running too frequently. It shouldn’t be problematic, though it would be nice to know which job it is, and why it’s giving that error.

There’s no chance you have a double-configuration of cron jobs, and have them running twice per minute? If you turn them off, do they stop?

You can also try raising your logging level to DEBUG and see if that way you can figure out what it’s trying to do.

The decision on whether to go back to 7.8 (reverting to a backup - there is no real “downgrade” option) should be made based on the features you use and how you use them (especially the theme, and the email module).

I had a double crontab as you thought. So stupid when I found it. Real newbie in this crontab stuff. But fixing it hasn’t solved my problem.

I also made a clean install of v7.8.8 on the same server in which the problem also occurs. Nginx showing the same upstream timed out error

I just found this in the suitecrm log

Tue Nov 14 00:04:41 2017 [1887][1][FATAL] SCHEDULERS: could not get an IMAP connection resource for ID [ 8e602bcc-9132-5f71-6972-5a09da9c33ae ]. Skipping mailbox [ maarten@maartenprovo.be ].

That upstream error is not common in SuiteCRM, I’ve never seen it. Since you’re using nginx, which is much less common with SuiteCRM users than Apache, I tried googling it and found that it is a common problem with nginx:

https://distinctplace.com/2017/04/22/nginx-upstream-timed-out/

I set both read_timeout to 180, no success.

I found a script somewhere to test the working of php-imap, that one can succesfully connect and show the total number of messages in my inbox. It uses the ‘{imap.gmail.com:993/service=imap/ssl/validate-cert}INBOX’ syntax to connect with succes.

I also found a topic on github explaining some kind of password problem, so I hardcoded the password in InboundEmail.php, no succes.

I tried adding my ISP’s imap (telenet.be) but it gives me the same problem.

I have noticed php running very slow/crashing when I execute the test settings but the errorlog for php stays empty.

Maybe it’s time to try a nginx upgrade, or even a move to Apache. Or a PHP upgrade. Sometimes these things magically solve this kind of weird problems…

Ok, thank you very much for your help. Already running the latest versions.

But turns out, I can send newsletter without a working inbox :-D. It’s ok if it’s configured.