[horde] Kronolith ical hangs Imp / Kronolith

Tue Feb 12 13:48:59 UTC 2013

Zitat von Simon Wilson <simon at simonandkate.net>:

> ----- Message from Jan Schneider <jan at horde.org> ---------
>    Date: Tue, 12 Feb 2013 11:57:50 +0100
>    From: Jan Schneider <jan at horde.org>
> Subject: Re: [horde] Kronolith ical hangs Imp / Kronolith
>      To: horde at lists.horde.org
>
>
>> Zitat von Simon Wilson <simon at simonandkate.net>:
>>
>>> Latest H5.0.3, Kronolith 4.0.3
>>>
>>> Issue starts with an appointment sent to me by my wife from the  
>>> old H4 system. When I try and open the appointment email in Imp,  
>>> Imp hangs. Eventually it presents a red box with server  
>>> communication error. Httpd logs indicate php running out of memory:
>>>
>>> [Mon Feb 11 20:03:13 2013] [error] [client 192.168.1.155] PHP  
>>> Fatal error:  Allowed memory size of 134217728 bytes exhausted  
>>> (tried to allocate 512 bytes) in  
>>> /var/www/horde/kronolith/lib/Kronolith.php on line 498, referer:  
>>> https://server.simonandkate.net/imp/dynamic.php?page=mailbox
>>>
>>> Boosted php to 512MB from 128MB, and try again. Same, just takes  
>>> longer to give up:
>>>
>>> [Mon Feb 11 20:27:07 2013] [error] [client 192.168.1.155] PHP  
>>> Fatal error:  Allowed memory size of 536870912 bytes exhausted  
>>> (tried to allocate 77 bytes) in  
>>> /var/www/horde/kronolith/lib/Kronolith.php on line 498, referer:  
>>> https://server.simonandkate.net/imp/dynamic.php?page=mailbox
>>>
>>> Whilst eventually timing out, CPU hits 100% and stays there, httpd process.
>>>
>>> I then tried loading Kronolith on H5 - same thing happens, it  
>>> hangs on "Loading Calendars" in the sidebar.
>>
>> With the same error in the logs?
>
> Not as far as I can see. The 'access an appointment' from Katie  
> action in Imp returns these:
>
> PHP Fatal error:  Allowed memory size of 134217728 bytes exhausted  
> (tried to allocate 101 bytes) in  
> /var/www/horde/kronolith/lib/Kronolith.php on line 498, referer:  
> https://server.simonandkate.net/imp/dynamic.php?page=mailbox
>
> With errors on either line 498, 525, or 526 (that's the only  
> differences, other than a larger memory amount when I boosted it).

That's all the same code part where we build the event list from all  
events retrieved from the calendar backend (remote calendar in your  
case).

> Accessing Kronolith did not generate any httpd or horde log error  
> (albeit Horde was set to CRIT).

You got the meaning of log levels wrong. If you want *more* log  
entries, you need to *lower* the log level, not *raise* it.

> As long as Kronolith was set to access my wife's shared ics Calendar  
> from the h4 system, both actions (open an invite from that person,  
> and open Kronolith) failed by long timeout - the invite with a red  
> error msg in Imp, the opening Kronolith with the never-ending  
> "opening calendars" message.

A timeout should always be accompanied with a log entry, if not in the  
Horde log, then at least in the webserver/php log.

>>> Horde error log, when set to INFO, gives up some useful information:
>>>
>>> 2013-02-11T20:27:43+10:00 WARN: HORDE [kronolith] The remote  
>>> server at  
>>> https://mail.simonandkate.net/rpc.php/kronolith/katie/OPAyfdJO7vlN37eRNqEXFcA.ics doesn't support an WebDAV protocol version 3. [pid 15869 on line 626 of  
>>> "/var/www/horde/kronolith/lib/Driver/Ical.php"]
>>
>> This is unrelated and just a warning.
>
> Removing the ability to access the shared calendar by denying  
> permission at the h4 source allowed h5 Kronolith to run - instantly.  
> It also let me access the appointments. It also removed those  
> warnings. But it's unrelated? It may not be the cause, but seems  
> it's likely 'related'...

Well, it's obviously caused by accessing the remote calendar, but it's  
unrelated to your issue.

>>
>>> mail.simonandkate.net is the old one, and I have Katie's calendar  
>>> published from H4 as an ical. That has been working fine. I can  
>>> open the .ics file that link presents with Outlook and it works  
>>> fine. But now for some reason trying to open an appointment from  
>>> her in Imp, or trying to open Kronolith at all, kills Horde when  
>>> trying to retrieve and access the ical.
>>>
>>> Fixed it by removing share permissions in Katie's calendar (h4),  
>>> then trying to open Kronolith again (h5), and it immediately gives  
>>> me an error, and successfully loads Kronolith.
>>>
>>>
>>> So my thoughts -
>>>
>>> 1. This is really ugly. If it can't open a remote calendar, it  
>>> should fail gracefully, and go around the roadblock.
>>
>> This is a fatal PHP error. Like the name implies, there is no way  
>> to handle those gracefully.
>
> So, our shiny new Horde / Imp system is accessing a third party  
> system (in this instance h4) potentially entirely out of our  
> control, and something about what it gets from that system crashes  
> the shiny new H5 setup. And there is no way that I can see to tell  
> Horde / Imp / Kronolith to NOT try and load that shared calendar,  
> without loading it to see what they are, which you can't because it  
> never loads. What if I didn't have access to the source server? So I  
> would have just borked the system because it's falling over trying  
> to access a shared calendar?

Yes, that's what could happen if there is a bug in software.

> Assuming that you are correct and there is nothing that can be done  
> to stop the fatal php error, what I am saying here is that there  
> should be a way to REMOVE a broken shared calendar before it tries  
> to access it. That is what I mean by handle the situation more  
> gracefully.

Sure there can be something done: finding out why this remote calendar  
is consuming so much memory.

>>> 2. You should be able to remove a remote calendar somehow if it  
>>> does fail to access it.
>>
>> Again, if PHP fatals, there isn't anything we could do.
>>
>>> Is this a known issue, or have I stuffed something up?
>>
>> No idea. Sounds like a infinite loop. You could try installing  
>> xdebug to stop php execution earlier if nesting goes too deep, plus  
>> you would get a backtrace in your error message.
>
> This should be fairly easy to replicate if we wanted to work out if  
> it's really an issue... I can give you access to the ics service on  
> my old h4 system if needed... :) Having said that, I accept that I  
> am probably alone in having stumbled on this combination, and that  
> noone else probably cares at all LOL.

A backtrace would be start. The ics file or url location could help too.
-- 
Jan Schneider
The Horde Project
http://www.horde.org/