Error when using Knit in Rstudio Server

wcmcsts · March 28, 2018, 7:11pm

Issue takes place when using RStudio Server Pro. Current R version is 3.4.3.

Student tries to Knit a project and receives the following error in the console:

Had no issues doing this two weeks ago, but issue started today. This is the second time this has happened. Six weeks ago, a user experienced the same issue. Resolution was to delete his account, but I'm hoping not to do that this time.

Steps to recreate issue:

Create new project.
Click Knit drop down on menu bar
Receive error.

When I look in the log files, this is what I find:

28 Mar 2018 00:12:40 [rsession-user12] ERROR Failed to find function: 'rmarkdown:::default_output_format'
LOGGED FROM: call@r/RExec.cpp#381

Steps I took in attempt to resolve the issue:

Removed rmarkdown package from students local R library, reinstalled it and then updated the packages so that the server's rmarkdown package would work. Commands used: remove.packages('rmarkdown'); update.packages()
After a suggestion from a stack overflow post, I found sever 00LOCK files in the user's R directory. They were 00LOCK-rmarkdown and looked like the this was the issue. After deleting them, restarting the RStudio Server, having the user log in again on a fresh tab in Chrome, it still didn't work and I received the error above.
Checked the shared R library (/usr/local/R) on Math to see if there were any locked (00LOCK) files. There were none.
I removed the user's .rstudio directory, .RData file and .Rhistory file from their account. Had them log back in to recreate the files and still no luck.
Removed rmarkdown while logged in as an administrator, reinstalled it, and then updated all the packages. Still nothing.

If anybody has any suggestions on how to resolve, please let me know. I can't recreate the issue unless it is already happening. I've been banging my head against a wall trying to figure out what is wrong, but I can't seem to find an answer. Has anyone else experienced this? If more information is needed, I'll supply it.

Thanks,

hadley · March 29, 2018, 2:59pm

A careful read of the error message suggests it's more likely to be a problem with htmltools than rmarkdown.

In general, in this sort of case, I'd recommend reproducing in R (by copying and pasting the command that from the top of the RMarkdown pane), so then you can get a traceback. It might not help here, but in general the traceback will be useful for localising the problem.

kevinushey · March 29, 2018, 3:57pm

Where are your R packages installed? Are they by any chance installed on a networked filesystem? Is it possible the connection to that system is spotty (so that R believes files are not available during periods where the network filesystem is disconnected / unmounted)?

It would also be helpful to see the output of:

.libPaths()
utils::sessionInfo()
searchpaths()

when this error occurs.

wcmcsts · March 30, 2018, 4:18pm

.libPaths()
[1] "/usr/local/home/dlp/R/x86_64-pc-linux-gnu-library/3.4"
[2] "/usr/local/lib/R/site-library"                        
[3] "/usr/lib/R/site-library"                              
[4] "/usr/lib/R/library"

> utils::sessionInfo()
R version 3.4.3 (2017-11-30)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Ubuntu 14.04.5 LTS

Matrix products: default
BLAS: /usr/lib/libblas/libblas.so.3.0
LAPACK: /usr/lib/lapack/liblapack.so.3.0

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     

loaded via a namespace (and not attached):
[1] compiler_3.4.3

> searchpaths()
[1] ".GlobalEnv"                   "/usr/lib/R/library/stats"    
[3] "/usr/lib/R/library/graphics"  "/usr/lib/R/library/grDevices"
[5] "/usr/lib/R/library/utils"     "/usr/lib/R/library/datasets" 
[7] "/usr/lib/R/library/methods"   "Autoloads"                   
[9] "/usr/lib64/R/library/base"

kevinushey · March 30, 2018, 8:30pm

I'm surprised that the base package is being found in a different folder from all of the other packages (within /usr/lib64 rather than /usr/lib). No idea if that's related, but it might be worth figuring out why that's the case.

I'm also surprised that the home folder lives at /usr/local/home rather than just /home. Is that a directory that gets mounted for the user, or similar?

My suspicion is still that this is related to the use of a networked filesystem (especially if the user is attempting to install packages into a local user library that lives on this mount). Any chance that could be the case?

wcmcsts · March 30, 2018, 8:44pm

I did some digging into htmltools and even reinstalling the packages didn't help.

I don't have the affected account with me, but I'll test the traceback and submit the results when I can.

Thanks!

wcmcsts · March 30, 2018, 8:48pm

There's probably a good chance that it has something to do with the networked file system. I usually go through the mounted accounts and remove their R libraries from their /home/ directories. In doing so, I hope to force the accounts to use the server library. I'll do some more poking into that.

I'll be honest and say it actually surprised me during setup that RStudio Server Pro accepted the mounted NFS accounts instead of me having to create separate ones on the host server. So it doesn't surprise me that my issue may spawn from there as well.

The /usr/local/home is only for one account. Usually the accounts are mounted to /home/ through NFS.

wcmcsts · April 5, 2018, 11:13pm

So, to close the case (kinda), I have an interim solution to my problem.

In our situation, the same account that is used to log into our local lab computers is the same that the students use to log into RStudio Server Pro on the web. The issue was that the server and the local accounts carry their own R libraries.

Simple solution was to blow away the local R libraries on the accounts. This resulted in the students having to reinstall all of their packages when they went to use the lab computers; however, if they don't reinstall their local libraries, when the use RStudio Server Pro, they use the server's libraries.

Going forward, I'm going to either have to make the decision of removing RStudio and R from the lab computers and forcing the use of RStudio Server Pro, or creating new accounts for RStudio Server Pro for each student.

Thanks to those that responded and I hope this helps others who may encounter this issue.