While trying to deploy a Shiny app on RStudio Connect I receive the following error:
----- Deployment error -----
Error: HTTP 500
GET http://10.80.40.13:3939/__api__/tasks/YUJMyIjVyh3Pm87i?first_status=487
<h1>An error has occurred</h1>
<p id="message">database is locked</p>
The server is not under heavy load and currently there are only 5 users and one app on the server.
I tried a few steps from here. Killed the process using the db. I then moved connect.db to another location and then copied it back to /var/lib/rstudio-connect/db/ . After this step I could not even login to RStudio Connect. I did an integrity check on connect.db and found it to be ok butt still no joy. Next, I restored the db to a previous version. I am able to login now but while deploying the Shiny app, still receiving the same error.
The app I am trying to deploy has already been successfully deployed on the server. What I am trying to deploy now is a modified version of the same app, with the only change being an addition of a pickerInput() .
A couple of things to keep in mind for the future:
make sure to stop RStudio Connect before doing anything with the database, lest you end up with a corrupted database
When trying to kill a process, it is always best to try a kill first, before the extremekill -9 (which gives the process to chance to clean up after itself if it is in the middle of something)
Are there any processes on the server that use the connect.db other than RStudio Connect? I.e. any reports or anything that are accessing the database directly? (That is a bad pattern to follow, just for reference)
Do you have any information about the process using the database that you killed? Was it a Connect process? Was it some other process? The output of ps -aux on that process would probably be helpful.
@cole thanks for your reply. Currently on the server, there are 4 Rmd scripts which have been scheduled to gather some data using APIs periodically. They are not using connect.db. I didn't check the what the process was that was using the db before killing it.
So the Shiny application that I am trying to deploy is a brute of an application. It was running locally without any problem. I tried deploying it on Shiny Server and realized that the application would disconnect in less than 5 minutes. Closer inspection of the logs revealed that the C stack usage was really high leading to crashes. Spent the last couple of days pouring over the code trying to identify recursion in functions. Found some, made changes and now the application seems to work. I have no idea why it would lead to a db lock problem on RSC though.
That is super strange. I cannot imagine why that would happen either... and it is definitely concerning if Connect is running into itself. Was the R process itself crashing? If you run into the issue again and can pare it down to a reproducible example, it would be super useful for us to troubleshoot on our end and see if we can reproduce on an arbitrary Connect server. Do you know which version of RStudio Connect you are using, and do you mind sharing an example of the type of recursion that you teased out?
Related: are you familiar with Shiny Modules? They can be super helpful in paring down brutes
@cole thanks for your reply. There were a couple of reactive functions where I was referring to the function name within the function itself. I think that was leading to the problem of high C stack usage.
I am aware of Shiny Modules though haven't tried it. I have split the application into multiple R files for the server and UI code and I then source them within server.R and UI.R.
Ah very interesting. If that type of recursion interests you, the topic of tail recursion (also known as "trampolines") may interest you as well.
The nice thing about Shiny Modules is that you can run components independent of one another for more modular testing or re-use them multiple times in the same application (if you find yourself creating similar widgets / patterns that could be reusable).
Sounds like you're on a good path, though! Please do let us know if you run into any more issues with the database lock!
