[OPEN-ILS-DEV] giant error-log and missing database access

[K. Kohls]

Am 23.02.2011, 10:45 Uhr, schrieb K. Kohls <tengo-k at web.de>:

> Following that troubleshooting I get as far as step 7 when it comes to
> starting the OpenSRF C services, the result is antoher log file of errors
> after running grep ERR /openils/var/log/*.log

We managed to add the definitions in example.reporter-extension.sql to the  
database, but there are still some errors left.
The actual output of "grep ERR /openils/var/log/*.log" is attached.

Thanks for your kind help,

Kadda

> To answer that personal request I finally included hald of the name ;)
>
>
>
> Am 23.02.2011, 00:00 Uhr, schrieb Anoop Atre <anoop.atre at mnsu.edu>:
>
>> Hello K
>> Welcome! It would be good to know what version system, OpenSRF and
>> Evergreen you are using along with operating system information. Looking
>> at the error log it seems like ejabberd might not be running or is not
>> configured correctly.
>>
>> I would suggest running through this troubleshooting check list:
>>
>> http://open-ils.org/dokuwiki/doku.php?id=troubleshooting:checking_for_errors
>>
>> Another avenue to get help is on the IRC channel usually there is
>> someone around:
>>
>> http://open-ils.org/irc.php
>>
>> A personal request, could you update your email client to use your real
>> name? I'm guessing it starts with a "K" but it would be good to know : )
>>
>> Cheers
>>
>> On 02/22/2011 04:04 PM, K wrote:
>>> Hey there,
>>>
>>> past 8 hours this day we tried to fix our evergreen system or at least
>>> get it
>>> far enough to run even once. We just followed the steps of OpenSrf and
>>> Evergreen
>>> installation with all necessary parts included (I guess) on a linux
>>> server, htop
>>> tells all party are running and within the installation there didn't
>>> occure any
>>> significant problems.
>>>
>>> So today we first tried converting the MARC records into BRE JSON via
>>> script
>>> <http://www.open-ils.org/dokuwiki/doku.php?id=evergreen-admin:importing:bibrecords>
>>> (which finally worked pretty well) following the Gutenberg example with
>>> our own
>>> data. After figuring out .ingest can be ignored and perl may use .bre
>>> directly
>>> the database was filled with useful entries. Proving this via
>>> web-interface and
>>> matching IP-address didnt't work, entering any term into the search box
>>> didn't
>>> lead to results but just denied to react at all.
>>>
>>> Going through several steps of troubleshooting we managed to got to
>>> authentication with the srfsh command-line OpenSRF client with an
>>> enormous
>>> request time of about 60 seconds.
>>>
>>> The web-interface still doesn't work even if we get to the page of
>>> search
>>> results now (without any content though). The error-log can be found as
>>> appendix
>>> (is this the right term to use for a mail? can't tell sry). I would be
>>> glad if
>>> anyone is able to help us with this undefined problem or if there are
>>> any hints
>>> which things we can try to get through.
>>>
>>> greets
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ERR.log
Type: application/octet-stream
Size: 2275 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110223/ce3c66a0/attachment-0001.obj