I have a shiny server and actually I have been able to upload and use "online" some simple apps, and also the shiny and rmardown test works properly.
But then, when I try to use my own application (which works locally, on my computer), I get the following error message (I looked in log -> var/log/shiny-server):
su: ignore --preserve-environment, it's mutually exclusive to --login.
Loading required package: viridisLite
Loading required package: heatmaply
======================
Welcome to heatmaply version 0.14.1
Type citation('heatmaply') for how to cite the package.
Type ?heatmaply for the main documentation.
The github page is: https://github.com/talgalili/heatmaply/
Please submit your suggestions and bug-reports at: https://github.com/talgalili/heatmaply/issues
Or contact: <tal.galili#gmail.com>
======================
Listening on http://127.0.0.1:43894
Execution halted
The session info:
R version 3.5.0 (2018-04-23)
Platform: x86_64-redhat-linux-gnu (64-bit)
Running under: CentOS Linux 7 (Core)
Matrix products: default
BLAS/LAPACK: /usr/lib64/R/lib/libRblas.so
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=es_ES.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=es_ES.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=es_ES.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=es_ES.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_3.5.0
I reinstaled both packages, and I also try to call them in R (sudo -i R to use R in console and then library(viridisLite) and library(heatmaply)) and they both works without problem.
When I try to use my App, server gets disconected and I have to restart it (My app starts to charge but when I reach to log issue, stops working)
Maybe the R version has to do with my issue, but I tried to change it unsuccesfully.
Best rewards,
Daniel.
I have installated the last shiny-server version and also went to wired connection -> IPv4-settings and delete the additional DNS server. It works!
Related
I am using the mediation package to run a mediation analysis.
But when I call the mediate function, R eats up all RAM, then it eats up all swap, and then RStudio suddenly closes.
The same happens if I call Rscript from the terminal, and the terminal suddenly closes.
Here is measures for RAM and swap. Notice the peaks:
This happens both with the R 4.0.5 version that comes with the Fedora repository (which uses Open BLAS), both with a custom R 4.1.0 version I compiled from source against Intel MKL.
What is the cause of this, and how I can debug?
Here is my current sessionInfo():
> sessionInfo()
R version 4.1.0 (2021-05-18)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Fedora 34 (Workstation Edition)
Matrix products: default
BLAS/LAPACK: /opt/intel/oneapi/mkl/2021.2.0/lib/intel64/libmkl_gf_lp64.so.1
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=en_GB.UTF-8
[4] LC_COLLATE=en_US.UTF-8 LC_MONETARY=en_GB.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=en_GB.UTF-8 LC_NAME=C LC_ADDRESS=C
[10] LC_TELEPHONE=C LC_MEASUREMENT=en_GB.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
loaded via a namespace (and not attached):
[1] compiler_4.1.0 tools_4.1.0
If the application needs all RAM and all virtual RAM you definitely hit the hard limit of your computer. If the application now requests more RAM from the OS, that request has to fail. How do you expect the application to deal with it?
As we do not know why more RAM was requested (it could be a memory leak, it could be that the algorithm just requires that much) we cannot distinguish bug or feature, but we can try things around that.
One quite cheap thing to try is to increase virtual memory size. Execution will get slower (disk access is measured in ms as opposed to RAM access times measured in ns), but maybe you find a value that the application can complete the task with.
If you cannot find any limit on virtual memory and the application always crashes due to the out-of-memory situation, you are likely facing a bug.
In any case you may want to talk to the vendor about this perception.
I'm trying to connect to a remote MariaDB database through R using SSL authentication, but keep failing.
I can connect directly from the terminal using mysql -u -p -P -h --ssl-ca --ssl-key --ssl-cert --ssl-capath --ssl-cipher, so the certificate is valid and the connection is working.
In R, I'm trying to connect using two drivers, giving me two different errors:
using RMariaDB: Error: Failed to connect: SSL connection error: error:00000001:lib(0):func(0):reason(1)
using RMySQL: Failed to connect to database: Error: Access denied for user 'myUsername'#'myHostIP' (using password: YES)
I am providing the full path for the certificate files (same as the ones used with the working connection in the terminal), there is no issue with the permissions of these files.
I tried a fresh R install, a fresh MySQL/MariaDB install, downgrading RMariaDB, etc... and nothing has helped yet.
I also tried to set up odbc on Ubuntu, but did not succeed... However, I'm sure I can connect using straight RMariaDB and this is the solution I would prefer.
Here's my sessionInfo() output:
R version 3.6.3 (2020-02-29)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 18.04.4 LTS
Matrix products: default
BLAS: /usr/lib/x86_64-linux-gnu/blas/libblas.so.3.7.1
LAPACK: /usr/lib/x86_64-linux-gnu/lapack/liblapack.so.3.7.1
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C LC_TIME=fr_FR.UTF-8 LC_COLLATE=en_US.UTF-8 LC_MONETARY=fr_FR.UTF-8 LC_MESSAGES=en_US.UTF-8 LC_PAPER=fr_FR.UTF-8
[8] LC_NAME=C LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=fr_FR.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] RJDBC_0.2-7.1 rJava_0.9-11 RMySQL_0.10.19 DBI_1.1.0 RMariaDB_1.0.8
loaded via a namespace (and not attached):
[1] bit_1.1-15.2 compiler_3.6.3 hms_0.5.3 DBI_1.1.0 tools_3.6.3 Rcpp_1.0.3 bit64_0.9-7 vctrs_0.2.2 RMySQL_0.10.19 pkgconfig_2.0.3 rlang_0.4.4
Any hint?
There was a version issue between the RMariaDB package and some of its dependencies.
Updating all dependencies using devtools solved the problem.
I am trying to run the some unconstrained optimization on a large problem on
a super computer, so I am trying to use the ucminf (although this problem
also works if I use the ucminf option in optimx). When I run any simple
optimization, I get the following message:
Error in .Call("mfopt", fnstr, grstr, rho, PACKAGE = "ucminf") :
"mfopt" not available for .Call() for package "ucminf"
For simplicity, here is a simple bit of test code that gives me the error.
library(ucminf)
test<-function(x){
(x-3)^2}
ucminf(0,test)
All of this works fine on my personal computer, but does not work on the
super computer. I have tried this on R/3.5.0 and R/3.3.0 on the super
computer and they both give me the same error.
Here is my Session info.
R version 3.5.0 (2018-04-23)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: CentOS release 6.9 (Final)
Matrix products: default
BLAS: /usr/public/R/3.5.0.gnu/lib64/R/lib/libRblas.so
LAPACK: /usr/public/R/3.5.0.gnu/lib64/R/lib/libRlapack.so
locale:
[1] LC_CTYPE=en_US.iso885915 LC_NUMERIC=C
[3] LC_TIME=en_US.iso885915 LC_COLLATE=en_US.iso885915
[5] LC_MONETARY=en_US.iso885915 LC_MESSAGES=en_US.iso885915
[7] LC_PAPER=en_US.iso885915 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=en_US.iso885915 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] ucminf_1.0-5 numDeriv_2016.8-1
loaded via a namespace (and not attached):
[1] compiler_3.5.0
I have uninstalled and reinstalled the package using Rinstall('ucminf'). Does anyone have experience with this and how to fix it?
I have a headless R server which serves the recent rstudio-server.
I need to pass it some objects via svSocket.
Because the svSocket uses TCL/TK message queue, which needs a working X11 session I know I need to embed things in a virtual X11 environment.
I log into the server via ssh and in the command line I put the following commands:
sudo Xvfb :0 &
export DISPLAY=":0"
/usr/lib/rstudio-server/bin/rserver &
R
Then I log into the rstudio-server via its web interface and type these commands:
> library(svSocket)
> startSocketServer()
[1] TRUE
then, on this R session I put the following
> library(svSocket)
> con<-socketConnection(host='localhost', port=8888)
> evalServer(con,'2+2')
I expect to get "4" result, but instead the R hangs, never returning any prompt.
If I replace the rstudio-server with the regular R, everything works correctly.
What is so special in the way it treats rsession that this example breaks? How to fix it?
SessionInfo():
R version 3.2.3 (2015-12-10)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 16.04 LTS
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C
[3] LC_TIME=pl_PL.UTF-8 LC_COLLATE=en_US.UTF-8
[5] LC_MONETARY=pl_PL.UTF-8 LC_MESSAGES=en_US.UTF-8
[7] LC_PAPER=pl_PL.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C
[11] LC_MEASUREMENT=pl_PL.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
You need to mention the port number when you start the socket connection
> library(svSocket)
> startSocketServer(port=8888)
It should work after this.
We have a problem using RMarkdown on multiple operating systems.
Initially, an .Rmd file is created on a Linux system (Ubuntu 12.04 LTS) and then pushed to a GitHub repo.
It can be compiled ("knitted") without problems on this system.
It is then pulled on a Windows 7 machine with RStudio installed.
There, when trying to compile, the following error shows up:
Error in yaml::yaml.load(front_matter) :
Reader error: invalid leading UTF-8 octet: #FC at 66
Calls: <Anonymous> -> parse_yaml_front_matter -> <Anonymous> -> .Call
Execution halted
When creating another .Rmd file on the Windows system, it works flawlessly.
When creating another .Rmd file on the Windows system, and copying everything but the first few lines of the "problematic" file to the other .Rmd file, and compiling this file, it works flawlessly.
I compared both files in HEX (in Sublime) on both operating systems: They are EXACTLY the same.
Has somebody else seen that error before?
Update: It seems as if a German Umlaut ("ü") is causing the problem, as its UTF-8 "Escaped Unicode" is \uFC, according to http://www.endmemo.com/unicode/unicodeconverter.php
In general, it seems that Unicode is not correctly recognized by either R, RStudio or knitr on Windows. When I type in some Umlauts in a new .Rmd file, and knit it, I get output such as "öää". In RStudio > Tools > Global options, I set the Default text encoding to "UTF-8". And I also did that for R, in the RProfile.site file (options(encoding="UTF-8")).
Update 2: library(rmarkdown); sessionInfo() gives
R version 3.1.2 (2014-10-31)
Platform: x86_64-w64-mingw32/x64 (64-bit)
locale:
[1] LC_COLLATE=German_Switzerland.1252 LC_CTYPE=German_Switzerland.1252 LC_MONETARY=German_Switzerland.1252
[4] LC_NUMERIC=C LC_TIME=German_Switzerland.1252
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rmarkdown_0.4.2
loaded via a namespace (and not attached):
[1] digest_0.6.8 htmltools_0.2.6 tools_3.1.2
on Windows 7, whereas, on Ubuntu, it is:
R version 3.1.2 (2014-10-31)
Platform: x86_64-pc-linux-gnu (64-bit)
locale:
[1] LC_CTYPE=en_US.UTF-8 LC_NUMERIC=C 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 LC_PAPER=en_US.UTF-8 LC_NAME=C
[9] LC_ADDRESS=C LC_TELEPHONE=C LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C
attached base packages:
[1] stats graphics grDevices utils datasets methods base
other attached packages:
[1] rmarkdown_0.3.10
loaded via a namespace (and not attached):
[1] digest_0.6.8 htmltools_0.2.6 tools_3.1.2
I already suspect the problem to be the diverging locale... how do I fix this?
I am extremely late to this, but I solved the issue by changing the options encoding back to "native":
options(encoding="native")
And changing the default windows encoding to UTF-8 (which opened the pandora box of a non-negligible number of other issues related to the encoding of other programs; so, treat with caution).