You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@couchdb.apache.org by j d <do...@gmail.com> on 2010/03/11 17:38:05 UTC
test suites failing on 0.11.0b921503
Attempting to run any of the tests in the test suite page puts couchdb
into a loop that spits out the following error over and over:
/usr/local/lib/couchdb/bin/couchjs: error while loading shared
libraries: libjs.so: cannot open shared object file: No such file or
directory
[error] [<0.348.0>] OS Process Error <0.1578.0> ::
{os_process_error,{exit_status,127}}
Creating databases and documents and running the all_doc view seems to
work fine. I am still having problems with creating and using admin
accounts as talked about in my previous post (CouchDB 0.11.0b921503
user signup errors).
I have executed "make clean && make distclean && ./bootstrap &&
./configure --with-erlang=/usr/lib64/erlang/usr/include
--with-js-include=/usr/local/spidermonkey/include
--with-js-lib=/usr/local/spidermonkey/lib64 && make check && make"
I have also added the couchdb user using: "useradd --home-dir
/usr/local/var/lib/couchdb -r -M --shell /bin/bash --comment "CouchDB
Administrator" couchdb" Note that some of the options are different
then what is listed on the Installing_on_RHEL5 page. I have also
modified the ownerships and permissions as directed in the README. I
then used "passwd couchdb" to change the password.
I also get this error when starting up couchdb:
=ERROR REPORT==== 11-Mar-2010::11:19:23 ===
file:path_eval([".","/root"],".erlang"): permission denied
Apache CouchDB 0.11.0b921503 (LogLevel=info) is starting.
Apache CouchDB has started. Time to relax.
Though someone on the list said it is a harmless error.
I'm running RHEL5.1 x86_64. I believe all of my libraries are up to spec.
Re: test suites failing on 0.11.0b921503
Posted by Jan Lehnardt <ja...@apache.org>.
On 11 Mar 2010, at 16:20, j d wrote:
> Completely removing all couchdb install files and database files, then
> doing a clean re-build and re-running the tests leaves just one error
> left:
>
> stats:
> 1. # Assertion 'triggered, "We managed to force a all_dbs_active
> error."' failed: We managed to force a all_dbs_active error.
That one is an ephemeral failure. Try running the test a few times on it's own,
it should succeed eventually. HTTP is hard :)
Cheers
Jan
--
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
Completely removing all couchdb install files and database files, then
doing a clean re-build and re-running the tests leaves just one error
left:
stats:
1. # Assertion 'triggered, "We managed to force a all_dbs_active
error."' failed: We managed to force a all_dbs_active error.
Re: test suites failing on 0.11.0b921503
Posted by J Chris Anderson <jc...@couch.io>.
On Mar 11, 2010, at 3:50 PM, j d wrote:
> Also, a lot of test suite databases where not removed.
>
We don't remove the test suite databases as you might need those for diagnosing error causes.
As far as the changes test error you saw, that is a matter of browser timing (it seems to pass more than 1/2 the time) so occasional failures aren't a broken CouchDB, just the nature of the beast.
The reader_acl errors you saw should be fixed in latest trunk (they are also a timing issue, I think). Maybe upgrading will help here.
Chris
> test_suite_db/with_slashes 4.1 KB 2 2
> test_suite_users 8.1 KB 2 2
> test_suite_db_a 12.1 KB 1 2
> test_suite_filtered_rep_db_b 8.1 KB 2 2
> test_suite_rep_docs_db_b 4.1 KB 2 2
> test_suite_rep_docs_db_a 4.1 KB 3 3
> _users 4.1 KB 1 1
> test_suite_filtered_rep_db_a 20.1 KB 5 5
> test_suite_db_b 8.1 KB 1 3
> test_suite_db 4.1 KB 2 2
> test_suite_reports 12.1 KB 2 2
Re: test suites failing on 0.11.0b921503
Posted by Jan Lehnardt <ja...@apache.org>.
On 11 Mar 2010, at 15:50, j d wrote:
> Also, a lot of test suite databases where not removed.
The non-removing is intentional. It makes it easier to find issue when we can inspect the state of a database in a failed test case.
Cheers
Jan
--
>
> test_suite_db/with_slashes 4.1 KB 2 2
> test_suite_users 8.1 KB 2 2
> test_suite_db_a 12.1 KB 1 2
> test_suite_filtered_rep_db_b 8.1 KB 2 2
> test_suite_rep_docs_db_b 4.1 KB 2 2
> test_suite_rep_docs_db_a 4.1 KB 3 3
> _users 4.1 KB 1 1
> test_suite_filtered_rep_db_a 20.1 KB 5 5
> test_suite_db_b 8.1 KB 1 3
> test_suite_db 4.1 KB 2 2
> test_suite_reports 12.1 KB 2 2
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
Also, a lot of test suite databases where not removed.
test_suite_db/with_slashes 4.1 KB 2 2
test_suite_users 8.1 KB 2 2
test_suite_db_a 12.1 KB 1 2
test_suite_filtered_rep_db_b 8.1 KB 2 2
test_suite_rep_docs_db_b 4.1 KB 2 2
test_suite_rep_docs_db_a 4.1 KB 3 3
_users 4.1 KB 1 1
test_suite_filtered_rep_db_a 20.1 KB 5 5
test_suite_db_b 8.1 KB 1 3
test_suite_db 4.1 KB 2 2
test_suite_reports 12.1 KB 2 2
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
First I do want to thank everyone for their help, you guys have been
persistent and fast to respond.
Most of the tests now pass except for an exception and some failures.
changes:
Exception Raised:
{"message":"JSON.parse","fileName":"http://64.127.16.171:5984/_utils/script/couch_test_runner.js?0.11.0","lineNumber":146,"stack":"(false)@http://64.127.16.171:5984/_utils/script/couch_test_runner.js?0.11.0:146\u000arun(-6)@http://64.127.16.171:5984/_utils/script/couch_test_runner.js?0.11.0:83\u000a"}
reader_acl:
1. # Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
2. # Assertion failed: CouchDB.session().userCtx.name == "jchris@apache.org"
3. # Assertion failed: false && "can't open a doc from a secret db"
4. # Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
5. # Assertion failed: CouchDB.login("jchris@apache.org", "funnybone").ok
6. # Assertion failed: CouchDB.session().userCtx.roles.indexOf("_admin") == -1
reduce_builtin:
1. # Assertion failed: db.info().doc_count == (i - 1) * 10 * 11 + (j + 1) * 11
stats:
1. # Assertion 'triggered, "We managed to force a all_dbs_active
error."' failed: We managed to force a all_dbs_active error.
The log file is huge but I am see this so far:
[Thu, 11 Mar 2010 21:23:34 GMT] [debug] [<0.95.0>] 'PUT'
/test_suite_db/mudfish {1,1}
Headers: [{'Accept',"text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"},
{'Accept-Charset',"ISO-8859-1,utf-8;q=0.7,*;q=0.7"},
{'Accept-Encoding',"gzip,deflate"},
{'Accept-Language',"en-us,en;q=0.5"},
{'Connection',"keep-alive"},
{'Content-Length',"55"},
{'Content-Type',"text/plain; charset=UTF-8"},
{'Host',"64.127.16.171:5984"},
{'Keep-Alive',"300"},
{'Referer',"http://64.127.16.171:5984/_utils/couch_tests.html?script/couch_tests.js"},
{'User-Agent',"Mozilla/5.0 (Windows; U; Windows NT 6.0;
en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 GTB6 (.NET CLR
3.5.30729)"}]
[Thu, 11 Mar 2010 21:23:34 GMT] [debug] [<0.95.0>] OAuth Params: []
[Thu, 11 Mar 2010 21:23:34 GMT] [debug] [<0.95.0>] Minor error in HTTP
request: {doc_validation,
<<"Bad special document member: _fan">>}
[Thu, 11 Mar 2010 21:23:34 GMT] [debug] [<0.95.0>] Stacktrace:
[{couch_doc,transfer_fields,2},
{couch_httpd_db,couch_doc_from_req,3},
{couch_httpd_db,db_doc_req,3},
{couch_httpd_db,do_db_req,2},
{couch_httpd,handle_request_int,5},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}]
[Thu, 11 Mar 2010 21:23:34 GMT] [info] [<0.95.0>] 68.33.0.252 - -
'PUT' /test_suite_db/mudfish 500
[Thu, 11 Mar 2010 21:23:34 GMT] [debug] [<0.95.0>] httpd 500 error response:
{"error":"doc_validation","reason":"Bad special document member: _fan"}
Firebug showed some bad requests as well. Not sure if those log
errors or firebug errors correlate to the failed tests.
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
>> Also: LD_LIBRARY_PATH is a bit fragile. Better is this, so you don't need
>> any environment variables:
>>
>> echo "/usr/local/spidermonkey/lib64" >/etc/ld.so.conf.d/spidermonkey.conf
>> ldconfig
>>
> ok i'll try this first.
>
Thank you! The first test passes, now I'll run the rest (with debug
logging on).
Re: test suites failing on 0.11.0b921503
Posted by Brian Candler <B....@pobox.com>.
On Thu, Mar 11, 2010 at 04:21:58PM -0500, j d wrote:
> All dependences for couchjs show up under that command, are any out-of-date?
>
> ldd /usr/local/lib/couchdb/bin/couchjs
> libm.so.6 => /lib64/libm.so.6 (0x0000003c54c00000)
I was wondering whether any pointed to "not found".
It must be that your LD_LIBRARY_PATH environment variable wasn't propagating
through erlang to couchjs - setting it permanantly in ldconfig fixed that.
B.
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
>
> Try this at command line:
>
> ldd /usr/local/lib/couchdb/bin/couchjs
>
> What does it show?
>
All dependences for couchjs show up under that command, are any out-of-date?
ldd /usr/local/lib/couchdb/bin/couchjs
libm.so.6 => /lib64/libm.so.6 (0x0000003c54c00000)
libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x00002aaaaaac9000)
libidn.so.11 => /usr/lib64/libidn.so.11 (0x0000003c5e000000)
libldap-2.3.so.0 => /usr/lib64/libldap-2.3.so.0 (0x0000003c56800000)
librt.so.1 => /lib64/librt.so.1 (0x0000003c59800000)
libssl.so.6 => /lib64/libssl.so.6 (0x0000003c5dc00000)
libcrypto.so.6 => /lib64/libcrypto.so.6 (0x0000003c5cc00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003c54800000)
libz.so.1 => /usr/lib64/libz.so.1 (0x0000003c55400000)
libjs.so => /usr/local/spidermonkey/lib64/libjs.so (0x00002aaaaad1a000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003c55000000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x0000003c62600000)
libc.so.6 => /lib64/libc.so.6 (0x0000003c54400000)
liblber-2.3.so.0 => /usr/lib64/liblber-2.3.so.0 (0x0000003c56000000)
libresolv.so.2 => /lib64/libresolv.so.2 (0x0000003c5bc00000)
libsasl2.so.2 => /usr/lib64/libsasl2.so.2 (0x0000003c55800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003c54000000)
libgssapi_krb5.so.2 => /usr/lib64/libgssapi_krb5.so.2
(0x0000003c5d400000)
libkrb5.so.3 => /usr/lib64/libkrb5.so.3 (0x0000003c5d800000)
libcom_err.so.2 => /lib64/libcom_err.so.2 (0x0000003c5b800000)
libk5crypto.so.3 => /usr/lib64/libk5crypto.so.3 (0x0000003c5d000000)
libkrb5support.so.0 => /usr/lib64/libkrb5support.so.0
(0x0000003c5c400000)
libkeyutils.so.1 => /lib64/libkeyutils.so.1 (0x0000003c5c000000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x0000003c56c00000)
libsepol.so.1 => /lib64/libsepol.so.1 (0x0000003c57400000)
> Also: LD_LIBRARY_PATH is a bit fragile. Better is this, so you don't need
> any environment variables:
>
> echo "/usr/local/spidermonkey/lib64" >/etc/ld.so.conf.d/spidermonkey.conf
> ldconfig
>
ok i'll try this first.
> Even better is to set LD_RUN_PATH when you build couchdb, so that it has the
> location of its library built into the binary.
>
> B.
>
...then this.
Re: test suites failing on 0.11.0b921503
Posted by Brian Candler <B....@pobox.com>.
On Thu, Mar 11, 2010 at 11:38:05AM -0500, j d wrote:
> Attempting to run any of the tests in the test suite page puts couchdb
> into a loop that spits out the following error over and over:
>
> /usr/local/lib/couchdb/bin/couchjs: error while loading shared
> libraries: libjs.so: cannot open shared object file: No such file or
> directory
Try this at command line:
ldd /usr/local/lib/couchdb/bin/couchjs
What does it show?
Also: LD_LIBRARY_PATH is a bit fragile. Better is this, so you don't need
any environment variables:
echo "/usr/local/spidermonkey/lib64" >/etc/ld.so.conf.d/spidermonkey.conf
ldconfig
Even better is to set LD_RUN_PATH when you build couchdb, so that it has the
location of its library built into the binary.
B.
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
>
> Did you ever try installing the pre-built binary? If you can't get
> shared libraries to load, you've got something wonky going on. Try
> hitting the LD_ debug environement variable (which I don't know
> offhand). You might've hit a bitness problem somewhere.
>
>
> --
> --
> Andrew Melo
>
I will try and install the pre-built next. Not sure about the LD_
debug stuff, but i'll take a look at that to.
While I do that, I would like to point out that couchdb must be
executing some javascript as it wouldn't be able to *compile* and
execute views right? The "no such file" error may be erroneous.
Also, it appears that the error is occurring on a newly spawned
process, could this be part of the problem? I've attached my log file
for those interested.
Re: test suites failing on 0.11.0b921503
Posted by Andrew Melo <an...@gmail.com>.
On Thu, Mar 11, 2010 at 2:16 PM, j d <do...@gmail.com> wrote:
>>
>> also, check that the library is actually names libjs.so, I had a
>> problem once where the file installed didn't have the right name
>>
>
> Yes libjs.so is there. I think i'll turn debug logging on. I *was*
> going to have a cool demo tomorrow and show off couchdb and lucene
> spatial searching stuff. Looks like I'll be switching to postGIS.
>
Did you ever try installing the pre-built binary? If you can't get
shared libraries to load, you've got something wonky going on. Try
hitting the LD_ debug environement variable (which I don't know
offhand). You might've hit a bitness problem somewhere.
--
--
Andrew Melo
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
>
> also, check that the library is actually names libjs.so, I had a
> problem once where the file installed didn't have the right name
>
Yes libjs.so is there. I think i'll turn debug logging on. I *was*
going to have a cool demo tomorrow and show off couchdb and lucene
spatial searching stuff. Looks like I'll be switching to postGIS.
Re: test suites failing on 0.11.0b921503
Posted by Andrew Melo <an...@gmail.com>.
On Thu, Mar 11, 2010 at 1:35 PM, Dan Smythe <xk...@gmail.com> wrote:
> This sounds more like a linux file permissions issue than anything. Check
> em.
also, check that the library is actually names libjs.so, I had a
problem once where the file installed didn't have the right name
>
> --Dan
>
> On Thu, Mar 11, 2010 at 10:06 AM, j d <do...@gmail.com> wrote:
>
>> >
>> > you need to add the location of libjs.so to LD_LIBRARY_PATH
>> >
>>
>> That's in there...
>>
>>
>> LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib64:/usr/local/spidermonkey/lib64:/usr/local/lib
>>
>> Should have mentioned this before so you wouldn't have wasted your
>> time. It's not in the standard place "/js/" or "/usr/local/lib64"
>> though, could be part of the problem. Maybe its hard coded somewhere
>> in couch or the default is still being used?
>>
>
--
--
Andrew Melo
Re: test suites failing on 0.11.0b921503
Posted by Dan Smythe <xk...@gmail.com>.
This sounds more like a linux file permissions issue than anything. Check
em.
--Dan
On Thu, Mar 11, 2010 at 10:06 AM, j d <do...@gmail.com> wrote:
> >
> > you need to add the location of libjs.so to LD_LIBRARY_PATH
> >
>
> That's in there...
>
>
> LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib64:/usr/local/spidermonkey/lib64:/usr/local/lib
>
> Should have mentioned this before so you wouldn't have wasted your
> time. It's not in the standard place "/js/" or "/usr/local/lib64"
> though, could be part of the problem. Maybe its hard coded somewhere
> in couch or the default is still being used?
>
Re: test suites failing on 0.11.0b921503
Posted by j d <do...@gmail.com>.
>
> you need to add the location of libjs.so to LD_LIBRARY_PATH
>
That's in there...
LD_LIBRARY_PATH=/usr/lib64:/usr/local/lib64:/usr/local/spidermonkey/lib64:/usr/local/lib
Should have mentioned this before so you wouldn't have wasted your
time. It's not in the standard place "/js/" or "/usr/local/lib64"
though, could be part of the problem. Maybe its hard coded somewhere
in couch or the default is still being used?
Re: test suites failing on 0.11.0b921503
Posted by Andrew Melo <an...@gmail.com>.
On Thu, Mar 11, 2010 at 10:38 AM, j d <do...@gmail.com> wrote:
> Attempting to run any of the tests in the test suite page puts couchdb
> into a loop that spits out the following error over and over:
>
> /usr/local/lib/couchdb/bin/couchjs: error while loading shared
> libraries: libjs.so: cannot open shared object file: No such file or
> directory
you need to add the location of libjs.so to LD_LIBRARY_PATH
> [error] [<0.348.0>] OS Process Error <0.1578.0> ::
> {os_process_error,{exit_status,127}}
>
> Creating databases and documents and running the all_doc view seems to
> work fine. I am still having problems with creating and using admin
> accounts as talked about in my previous post (CouchDB 0.11.0b921503
> user signup errors).
>
> I have executed "make clean && make distclean && ./bootstrap &&
> ./configure --with-erlang=/usr/lib64/erlang/usr/include
> --with-js-include=/usr/local/spidermonkey/include
> --with-js-lib=/usr/local/spidermonkey/lib64 && make check && make"
>
> I have also added the couchdb user using: "useradd --home-dir
> /usr/local/var/lib/couchdb -r -M --shell /bin/bash --comment "CouchDB
> Administrator" couchdb" Note that some of the options are different
> then what is listed on the Installing_on_RHEL5 page. I have also
> modified the ownerships and permissions as directed in the README. I
> then used "passwd couchdb" to change the password.
>
> I also get this error when starting up couchdb:
>
> =ERROR REPORT==== 11-Mar-2010::11:19:23 ===
> file:path_eval([".","/root"],".erlang"): permission denied
> Apache CouchDB 0.11.0b921503 (LogLevel=info) is starting.
> Apache CouchDB has started. Time to relax.
>
> Though someone on the list said it is a harmless error.
>
> I'm running RHEL5.1 x86_64. I believe all of my libraries are up to spec.
>
--
--
Andrew Melo