Kolab/Roundcube/iRony very slow/hangs

[Daniel]

On 8/10/18 1:48 PM, Jan Kowalsky wrote:
> Hi Daniel,
>
> Am 01.08.2018 um 17:13 schrieb Daniel:
>
>> What does not work good is very slow
>>    * Sending an Calender Invitation to another E-Mail-Addresse e.g. an
>> gmail-address
>>      * sending an invit via Roundcube to an gmail-address
>>      * Event is added, and looks good
> ok, no problem so far.
>
>>      * after approx 10sec. Roundcube Calender spins and says "Refreshing"
>>      * All events disapear during this time
> this is something I also see sometimes. You can try to add some
> debug-level in roundcube (config.inc.php) and show output of the several
> logfiles (ldap, sql, imap could be relevant).
>
>>      * Gmail receives the invit in approx 30 Minutes or longer
> have a look at mail.log how the mail flow. Are the emails to gmail are
> sent immediately? Does the delay is caused from your mailserver or from
> gmail (maybe graylisting).
>
> If the mail needs that long until it's send out by postfix:
> iTip-Messeages are processed by wallace (you also can have a look at
> pykolab-log /var/log/kolab/pykolab.log - but set the debug level in
> /etc/default/wallace to -d 8 or 9 ....)
>
>>      * Looking at the runnning processes on the server via htop, it looks
>> good. No process is running at a height cpu rate
>>      * During that time, I cannot sync mails, send mails from or to the
>> kolab server
>>
> you mean during this 30 minutes? This sounds strange. Wallace should not
> interact with imap at all.
>
> Anything in mail.log / syslog during this time?
>
> Regards
> Jan

Hello Jan,

thank you for your reply.
I was already able to find some solutions to my problems.

First I had a configuration problem for the revers-dns-entry, and my FQDN.
My FQDN was not set in /etc/hosts, as I started with giving my server a 
fancy name (greek goddess), but for E-Mail I do have a simpler domain.
And the DNS MX entry was also wrong.

So that just showed issues on receiving mails and did not help on the 
other issue.

But, ok that was on me. :-)


Then I learned gmail has long generic sender addresses, which are longer 
then 64chars e.g.
3XzRnWwwJBkYnti20kpnq0kpouiqt.kwulivqmtnt2nn6j61m0.lm at calendar-server.bounces.google.com
The Issue and Workaround is explained here https://git.kolab.org/T2274 
but took me a while to find this.

And last but not least, it's an issue with wallaced and how it is 
started in Ubuntu16.04 LTS.
If wallaced is started by hand and without the --fork parameter, it 
works great.
But the start-stop-daemon in combination of wallaced's --fork parameter 
somehow leads to the effect that calendar-invitations/responses get 
stuck for ~30 minutes
In addition, a "systemctr restart wallaced" does not kill all 
wallaced-processes, because some still stuck somewhere and use ports.

So to work around this, I hacked an "old-school" init-script that simply 
starts wallaced in the background( unsing &), without start-stop-daemon 
and the --fork parameter.

Since then all runs like expected.
I tried to understand more from enabling more debug log information, but 
that did not help. I just noticed the wallaced behaviour as I started it 
manually with more debug flags, and the it all worked.


All the information above might help someone else :-)


Have a nice weekend

daniel