Running RStudio server, community edition inside a Docker container that shares a volume with the host occassionally produces a unique pattern of errors I haven't been able to make heads or tails of. We've seen quite a number of users report these (usually just in the form of warning messages), as detailed here: https://github.com/rocker-org/rocker/issues/260
In particular, I'm confused why RStudio should be looking for a path /home/ubuntu/rstudio/src/cpp/core/file_lock/LinkBasedFileLock.cpp:224 on a debian machine that has no ubuntu user, no idea what's generating said path.
Apologies if this esoteric issue would be better posted elsewhere, and many thanks for the help!
That path corresponds to the location of the cpp file on the machine that built RStudio, and is just intended as an aid for us to understand where the error's coming from.
The error suggests that RStudio is having trouble writing a file for its link-based file locking system, which in turn usually suggests that the filesystem it's on doesn't support links. Some notes in the issue linked above suggest that the underlying file system is Windows (NTFS?), which would explain the lack of link support.
The best advice I can give without more context is to try using advisory-based locks instead. This is documented in the admin guide under load balancing, but the file locking bits apply to all RStudio installations.
http://docs.rstudio.com/ide/server-pro/load-balancing.html#file-locking
1 Like
Thanks Jonathan, that bit on file locking is I think just what I was looking for. We've seen the same warning occur on instances running exclusively on Linux-based hosts. Only seems to happen though if the container is sharing volumes with the host, so probably has something to do with how Docker handles shared volumes.
Will definitely try switching to advisory-based locks and see how that works out. I don't personally run containers on any shared / NFS based systems, but wonder if advisory locks are going to create problems there for any users who do?
I do see these errors every time a session crashes as well. I wonder if shortening the expiration times would work (guess that only applies to link-based locks anyhow).