[horde] Kronolith ical hangs Imp / Kronolith

Tue Feb 12 12:13:06 UTC 2013

----- 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).

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

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.

>
>> 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'...

>
>> 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?

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.

>
>> 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.

Simon

--
Simon Wilson
M: 0400 12 11 16
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: PGP Digital Signature
URL: <http://lists.horde.org/archives/horde/attachments/20130212/028ee8bf/attachment.bin>