[Kolab-devel] Freebusy data not provided (native openSUSE)

Gunnar Wrobel wrobel at pardus.de
Sun Mar 8 16:46:10 CET 2009


Quoting Richard Bos <ml at radoeka.nl>:

> Hello Gunnar,
>
> Op zaterdag 07 maart 2009 14:55:06 schreef Gunnar Wrobel:
>> > What could be the reason that  $result = $this->_cache->load($access,
>> > $req_extended);
>> > fails?  Can the cause be in wrong directory names, of permissions?
>>
>> Yes, I believe so.
>>
>> > For now I have this:
>> > # grep cache *
>> > config.php:/* Location of the cache files */
>> > config.php:$conf['fb']['cache_dir']    = '/var/cache/freebusy';
>> >
>> > drwxrwxrwx 2 root root 4096 2009-03-05 21:57 /var/cache/freebusy/
>>
>> While this sounds unsafe :) the script should definitely have write access.
>
> That's not the default.  I did it, because of the errors.  I want to  
> be sure that the permissions are not in the way.
>
>
>> > # find /var/cache/freebusy
>> > /var/cache/freebusy
>> >
>> > Is it possible to print the values of $access and $req_extended?
>> >
>> > Hopefully, you have a clue what is wrong over here and can help me to
>> > solve it!
>>
>> Before going into the code, I'd rather like to have a look at the log
>> files. On a standard Kolab server the free/busy system will generate
>> two log files within /kolab/var/kolab-freebusy/log/. One is named
>> "freebusy.log" and the other "php-error.log". I'd be especially
>> interested in the second one. The fact that you don't see any further
>> output from the script indicates that a fatal error occured. In that
>> case PHP should log an error in the current PHP error log file. You
>> can also output the location of that file by adding a line like this
>> into the script:
>>
>>   var_dump(ini_get('error_log'));
>
> Very good that is what I needed, the output is:
> string(37) "/var/log/kolab/freebusy/php-error.log"
>
> I checked the log file before and it is always empty :(  Let's what  
> I have at the moment:
>
> kolab2:/var/log/kolab/freebusy # ls -ltr
> total 48
> -rw-r--r-- 1 wwwrun www   166 2009-03-06 22:57 php-error.log
> -rw-r--r-- 1 wwwrun www 42376 2009-03-06 23:53 freebusy.log
>
> The contents of php-error.log is:
> [06-Mar-2009 22:57:39] PHP Fatal error:  Call to a member function  
> exportvCalendar() on a non-object on line 90
>
> However, I just tried the freebusy*ifb call and that does not result  
> in an error message in the log.
>
> Ah, I just discovered that this entry in the log file is written  
> when I comment
> out line 216.
>
>> If this shows
>>
>>   bool(false)
>>
>> no errors get logged and you should fix your PHP configuration.
>>
>> Another important setting is
>>
>>   php -r "var_dump(ini_get('log_errors'));"
>
> That results in:
> string(1) "1"
>
>> 'log_errors' also needs to be turned on to get log entries in the error
>> log.
>
> # grep -R log_errors  /etc/php5/*
> /etc/php5/apache2/php.ini:log_errors = On
> /etc/php5/apache2/php.ini:; Set maximum length of log_errors. In  
> error_log information about the source is
> /etc/php5/apache2/php.ini:log_errors_max_len = 1024
>
> /etc/php5/cli/php.ini:log_errors = On
> /etc/php5/cli/php.ini:; Set maximum length of log_errors. In  
> error_log information about the source is
> /etc/php5/cli/php.ini:log_errors_max_len = 1024
>
>> You can also set 'display_errors' to be 'On'. In that case PHP errors
>> should be dumped to the browser.
>
> # grep errors /srv/www/htdocs/freebusy/config.php
> ini_set('display_errors', 1);
>
> It looks like the logs are set correctly.  I wonder why nothing gets  
> logged when line 216
> ($result = $this->_cache->load($access, $req_extended);) is  
> executed, hopefully you have a clue?

Hm, that might make it hard to find the error. I guess you hit  
something where an '@' is used to supress error messages. These are  
problematic for the exact reason that debugging can be quite difficult.

If you'd have a PHP debugger running it would be easy but I assume  
that is not the case.

Do you use the Kolab PHP libraries on a server that has an unpatched  
PHP (meaning not patched for Kolab)? In that case the PEAR-Net_IMAP  
library might be missing.

Cheers,

Gunnar
>
> --
> Richard
>
> _______________________________________________
> Kolab-devel mailing list
> Kolab-devel at kolab.org
> https://kolab.org/mailman/listinfo/kolab-devel
>



-- 
____ http://www.pardus.de _________________ http://gunnarwrobel.de _

E-mail : p at rdus.de                                 Dr. Gunnar Wrobel
Tel.   : +49 700 6245 0000                         Bundesstrasse 29
Fax    : +49 721 1513 52322                        D-20146 Hamburg
--------------------------------------------------------------------
    >> Mail at ease - Rent a kolab groupware server at p at rdus <<
--------------------------------------------------------------------


----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.




More information about the devel mailing list