[horde] Horde stopped working after upgrade

Arjen de Korte arjen+horde at de-korte.org
Tue Mar 5 22:00:45 UTC 2013


Citeren Michael M Slusarz <slusarz at horde.org>:

> Quoting Arjen de Korte <arjen+horde at de-korte.org>:
>
>> Citeren Arjen de Korte <arjen+horde at de-korte.org>:
>>
>>> After running
>>>
>>>   pear upgrade -c horde
>>>
>>> tonight, horde stopped working completely. Whatever I try, I get
>>> something like the following in the Apache logs:
>>>
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP Fatal
>>> error:  Call to a member function setObs() on a non-object in
>>> /usr/share/php5/PEAR/Horde/Perms/Sql.php on line 130, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP Stack
>>> trace:, referer: https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   1.
>>> {main}() /srv/www/htdocs/horde/test.php:0, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   2.
>>> Horde_Registry->pushApp() /srv/www/htdocs/horde/test.php:83, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   3.
>>> Horde_Registry->callAppMethod()
>>> /usr/share/php5/PEAR/Horde/Registry.php:1546, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   4.
>>> call_user_func_array() /usr/share/php5/PEAR/Horde/Registry.php:1141,
>>> referer: https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   5.
>>> Horde_Registry_Application->init()
>>> /usr/share/php5/PEAR/Horde/Registry.php:1141, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   6.
>>> Kronolith_Application->_init()
>>> /usr/share/php5/PEAR/Horde/Registry/Application.php:105, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   7.
>>> Kronolith::initialize()
>>> /srv/www/htdocs/horde/kronolith/lib/Application.php:75, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   8.
>>> Kronolith::hasApiPermission()
>>> /srv/www/htdocs/horde/kronolith/lib/Kronolith.php:907, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP   9.
>>> Horde_Registry->hasPermission()
>>> /srv/www/htdocs/horde/kronolith/lib/Kronolith.php:3068, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP  10.
>>> Horde_Perms_Base->hasPermission()
>>> /usr/share/php5/PEAR/Horde/Registry.php:1659, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP  11.
>>> Horde_Perms_Base->getPermissions()
>>> /usr/share/php5/PEAR/Horde/Perms/Base.php:249, referer:
>>> https://www.example.com/horde/test.php
>>> [Tue Mar 05 22:03:19 2013] [error] [client 192.168.1.121] PHP  12.
>>> Horde_Perms_Sql->getPermission()
>>> /usr/share/php5/PEAR/Horde/Perms/Base.php:144, referer:
>>> https://www.example.com/horde/test.php
>>> 192.168.1.121 - - [05/Mar/2013:22:03:19 +0100] "GET
>>> /horde/test.php?app=kronolith HTTP/1.1" 200 -
>>>
>>> I have no idea what went wrong and in which direction I should be
>>> looking for a solution. Any ideas?
>>
>> Never mind. It probably had to do with something in the cache.
>>
>> I tried clearing the cache through 'horde-clear-cache' before, but  
>> that resulted in the same kind of error message. After writing the  
>> above message, I did a last-ditch attempt to fix this by 'TRUNCATE  
>> TABLE horde_cache' in MySQL an lo-and-behold, this fixed the  
>> problems.
>>
>> So indeed there must have been something in the cache that  
>> prevented Horde from running properly. Too bad that also prevented  
>> 'horde-clear-cache' from doing its job.
>
> Do you have lzf or horde_lzf installed?

Yes (lzf) and no (horde_lzf).

> A recent change to Horde_Core now forces compression of cached  
> objects, but this **should** happen automatically.  (I can't  
> reproduce but one other dev noticed this).

I assume that the line

     $conf['cache']['compress'] = false;

is now obsolete then? It is still in 'config/conf.xml', so I didn't  
expect this to have changed.

> Note that you can't update in the middle of a session either and  
> expect things to work properly.

I use memcache for storing sessions, so restarting that (which I did)  
should have cleared all existing sessions, right? In that case we can  
be sure that there were no existing sessions that could be broken.  
What puzzles me, is that even 'horde-clear-cache' wasn't able to run,  
until I truncated the horde_cache table. I'm a bit surprized that it  
uses the cached info at all, since usually when one wants to clear the  
cache, there is something wrong with it.



More information about the horde mailing list