rApache and RSQLite (3.8) on CentOS6

[mbacou]

I have a problem using RSQLite 1.0.0 with rApache. In an interactive R console, everything works as expected, but when sending a request to the same package with OpenCPU/rApache, I get a version mismatch error.

$ curl http://198.105.216.164/ocpu/library/hcapi3/R/getLayer/json -d '{"var" : ["whea_h", "AEZ16_CLAS"], "by" : "ADM1_NAME_ALT"}' -X POST -H "Content-Type:application/json"
error in evaluating the argument 'drv' in selecting a method for function 'dbConnect': Error in SQLite(shared.cache = T) :
  SQLite mismatch between compiled version 3.8.6 and runtime version 3.6.20

SQLite 3.8 doesn't seem available from CentOS6 repos, so not sure what's the easiest way around.

Thanks, --Mel.

[hadley]

Try reinstalling RSQlite.
Hadley

On Sunday, November 9, 2014, Melanie Bacou notifications@github.com wrote:

I have a problem using RSQLite 1.0.0 with rApache. In an interactive R
console, everything works as expected, but when sending a request to the
same package with OpenCPU/rApache, I get a version mismatch error.

$ curl http://198.105.216.164/ocpu/library/hcapi3/R/getLayer/json -d '{"var" : ["whea_h", "AEZ16_CLAS"], "by" : "ADM1_NAME_ALT"}' -X POST -H "Content-Type:application/json"
error in evaluating the argument 'drv' in selecting a method for function 'dbConnect': Error in SQLite(shared.cache = T) :
SQLite mismatch between compiled version 3.8.6 and runtime version 3.6.20

SQLite 3.8 doesn't seem available from CentOS6 repos, so not sure what's
the easiest way around.

Thanks, --Mel.

—
Reply to this email directly or view it on GitHub
#60.

http://had.co.nz/

[mbacou]

I removed and reinstalled RSQLite (from github), but problem persists. It works no problem in an interactive R console, but fails through rApache/OpenCPU. This might be another CentOS or security issue unfortunately. Maybe I should report this to OpenCPU instead.

[mbacou]

Also, just to add I also tried to install RSQLite from source, but that didn't solve the rApache problem either.

[hadley]

What happened when you tried to install it from source?

[jeffreyhorner]

There might be another piece of software loading a sqlite library before
Rsqlite is loaded. You will want to check the apache binary, apache
modules, and any other r package that gets loaded on start and during
runtime. Scope out the Unix command ldd to analyze the apache binary and
the various modules and libraries. It prints out the dependant libraries
for a given binary or library.
On Nov 10, 2014 6:53 AM, "Hadley Wickham" notifications@github.com wrote:

What happened when you tried to install it from source?

—
Reply to this email directly or view it on GitHub
#60 (comment).

[mbacou]

@jeffreyhorner All right, I did try to start Apache without mod_php -- haven't tried to disable all other modules (painful process). Will try to use ldd systematically and report back here.
@hadley installing from source worked no problem, just didn't solve the rApache issue.

[jeffreyhorner]

One other thing. Check the output of .libPaths from rApache and make sure
you dont have old Rsqlite libraries in any of those paths.
On Nov 10, 2014 7:24 PM, "Melanie Bacou" notifications@github.com wrote:

@jeffreyhorner https://github.com/jeffreyhorner All right, I did try to
start Apache without mod_php -- haven't tried to disable all other modules
(painful process). Will try to use ldd systematically and report back here.
@hadley https://github.com/hadley installing from source worked no
problem, just didn't solve the rApache issue.

—
Reply to this email directly or view it on GitHub
#60 (comment).

[mbacou]

Here is for .libPaths through rApache. All very standard and there's only one RSQLite.

[
    "/usr/lib64/R/library",
    "/usr/lib/opencpu/library",
    "/usr/share/R/library"
]

I'm not loading a host of R packages aside from data.table, stringr, raster, rgdal. Here is a OpenCPU session info:

R version 3.1.1 (2014-07-10)
Platform: x86_64-redhat-linux-gnu (64-bit)

locale:
 [1] LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C              
 [3] LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8    
 [5] LC_MONETARY=en_US.UTF-8    LC_MESSAGES=en_US.UTF-8   
 [7] LC_PAPER=en_US.UTF-8       LC_NAME=C                 
 [9] LC_ADDRESS=C               LC_TELEPHONE=C            
[11] LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

attached base packages:
[1] stats     graphics  grDevices utils     datasets  methods   base     

other attached packages:
[1] opencpu_1.4.5

loaded via a namespace (and not attached):
 [1] base64enc_0.1-2    brew_1.0-6         chron_2.3-45       data.table_1.9.4  
 [5] DBI_0.3.1          devtools_1.6.1     digest_0.6.4       evaluate_0.5.5    
 [9] foreign_0.8-61     formatR_1.0        grid_3.1.1         hcapi3_3.0        
[13] httpuv_1.3.2       httr_0.5           jsonlite_0.9.13    knitr_1.7         
[17] lattice_0.20-29    openssl_0.1        pander_0.3.8       parallel_3.1.1    
[21] plyr_1.8.1         raster_2.3-12      RColorBrewer_1.0-5 Rcpp_0.11.3       
[25] reshape2_1.4       rgdal_0.9-1        rgeos_0.3-8        RSclient_0.7-2    
[29] RSQLite_1.0.0      sendmailR_1.2-1    sp_1.0-15          stringr_0.6.2     
[33] tools_3.1.1        unixtools_0.1-1  

Also looking for sqlite headers and libraries on the system. Both PHP and Python seem to come with their own as well. Could that be an issue?

$ locate sqlite3.h
/usr/include/sqlite3.h
/usr/lib64/R/library/RSQLite/include/sqlite3.h

$ locate sqlite.so
/usr/lib64/php/modules/pdo_sqlite.so
/usr/lib64/php-zts/modules/pdo_sqlite.so
/usr/lib64/qt4/plugins/sqldrivers/libqsqlite.so

$ locate sqlite3.so
/usr/lib64/libsqlite3.so
/usr/lib64/libsqlite3.so.0
/usr/lib64/libsqlite3.so.0.8.6
/usr/lib64/php/modules/sqlite3.so
/usr/lib64/php-zts/modules/sqlite3.so
/usr/lib64/python2.6/lib-dynload/_sqlite3.so
/usr/local/lib/python2.7/lib-dynload/_sqlite3.so

I tried ldd on Apache binary and modules:

ldd /usr/sbin/httpd
        linux-vdso.so.1 =>  (0x00007fff1e53f000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f08c29a1000)
        libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f08c2775000)
        libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f08c2555000)
        libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f08c2331000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f08c20fa000)
        libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f08c1ed1000)
        libdb-4.7.so => /lib64/libdb-4.7.so (0x00007f08c1b5d000)
        libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007f08c1931000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f08c1713000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f08c137f000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f08c117b000)
        /lib64/ld-linux-x86-64.so.2 (0x0000003b38a00000)
        libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f08c0f76000)
        libfreebl3.so => /lib64/libfreebl3.so (0x00007f08c0cfd000)

$ ldd /etc/httpd/modules/libphp5-zts.so
        linux-vdso.so.1 =>  (0x00007fff837ff000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fdfb613f000)
[etc...]

$ ldd /etc/httpd/modules/libphp5.so
        linux-vdso.so.1 =>  (0x00007fffe3119000)
        libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f22ad8d9000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f22ad6c8000)
[etc...]

I coudn't find one reference to sqlite. I'm starting to wonder if the error message might be one of those odd permission errors, maybe apache not having the right access to my .sqlite database? On that thought, the database is currently not inside my package, does it need to be?

[jeffreyhorner]

Definitely disable php and python support for apache, restart and see if
that fixes it.
On Nov 10, 2014 8:42 PM, "Melanie Bacou" notifications@github.com wrote:

Here is for .libPaths through rApache. All very standard and there's only
one RSQLite.

[
"/usr/lib64/R/library",
"/usr/lib/opencpu/library",
"/usr/share/R/library"
]

I'm not loading a host of R packages aside from data.table, stringr,
raster, rgdal, and RSQLite.

Also looking for sqlite headers and libraries on the system. Both PHP and
Python seem to come with their own as well. Could that be an issue?

$ locate sqlite3.h
/usr/include/sqlite3.h
/usr/lib64/R/library/RSQLite/include/sqlite3.h

$ locate sqlite3.so
/usr/lib64/libsqlite3.so
/usr/lib64/libsqlite3.so.0
/usr/lib64/libsqlite3.so.0.8.6
/usr/lib64/php/modules/sqlite3.so
/usr/lib64/php-zts/modules/sqlite3.so
/usr/lib64/python2.6/lib-dynload/_sqlite3.so
/usr/local/lib/python2.7/lib-dynload/_sqlite3.so

I tried ldd on Apache binary and modules:

ldd /usr/sbin/httpd
linux-vdso.so.1 => (0x00007fff1e53f000)
libm.so.6 => /lib64/libm.so.6 (0x00007f08c29a1000)
libpcre.so.0 => /lib64/libpcre.so.0 (0x00007f08c2775000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f08c2555000)
libaprutil-1.so.0 => /usr/lib64/libaprutil-1.so.0 (0x00007f08c2331000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f08c20fa000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f08c1ed1000)
libdb-4.7.so => /lib64/libdb-4.7.so (0x00007f08c1b5d000)
libapr-1.so.0 => /usr/lib64/libapr-1.so.0 (0x00007f08c1931000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f08c1713000)
libc.so.6 => /lib64/libc.so.6 (0x00007f08c137f000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f08c117b000)
/lib64/ld-linux-x86-64.so.2 (0x0000003b38a00000)
libuuid.so.1 => /lib64/libuuid.so.1 (0x00007f08c0f76000)
libfreebl3.so => /lib64/libfreebl3.so (0x00007f08c0cfd000)

$ ldd /etc/httpd/modules/libphp5-zts.so
linux-vdso.so.1 => (0x00007fff837ff000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007fdfb613f000)
[etc...]

$ ldd /etc/httpd/modules/libphp5.so
linux-vdso.so.1 => (0x00007fffe3119000)
libcrypt.so.1 => /lib64/libcrypt.so.1 (0x00007f22ad8d9000)
libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f22ad6c8000)
[etc...]

I coudn't find one reference to sqlite. I'm starting to wonder if the
error message might be one of those odd permission errors, maybe apache not
having the right access to my .sqlite database?

—
Reply to this email directly or view it on GitHub
#60 (comment).

[mbacou]

Jeff, so I can confirm the culprit is mod_php (I thought I had disabled it before logging this issue, but I must have done that wrong, apologies). Disabling that module takes care of the conflict and requests are successful again. I tried to re-enable it and moving the LoadModule R_module modules/mod_R.so directive to the top of the list, but that's a no go either.
For the record here is my version of php:

$ php --version
PHP 5.4.34 (cli) (built: Oct 16 2014 10:19:38)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
Installed Packages
php.x86_64                                 5.4.34-1.el6.remi                     @remi

Thanks!

[hadley]

This should be resolved in the dev version since we now always use the bundled sqlite

[github-actions]

This old thread has been automatically locked. If you think you have found something related to this, please open a new issue and link to this old issue if necessary.