Whenever I run a shiny app from ESS, it works, but I can't get the prompt back without killing the whole R session (like clicking the "Stop" button in RStudio). The normal Ctrl-C Cntrl-C, or Cntl-g don't work. So, I have to resort to Cntrl-x k. How do I kill the shiny process without killing R?
Well, I finally found out the reason. I had the option
(setq comint-prompt-read-only t)
set somewhere in my init files. Apparently, when this option is set it becomes impossible (well, beyond me anyway) to send a kill signal to the R process. I don't understand what is happening though. If I run a server directly from httpuv I can kill it even with the option set, but not when running an app through shiny.
you could use
C-c C-c
in iESS to quit the shiny app.
Related
I'm running a long R script, which takes 2 or 3 days to finish. I accidentally run another script, which, if it works as R usually does, will go in some queue and R will run it as soon as the first script is over. I need to stop that, as it would compromise the results from the first script. Is there a visible queue or any other way to stop R from running some code?
I'm working on an interactive session in R studio, on windows 10.
Thanks a lot for any help!
Assuming you're running in console (or interactive session in R studio, that's undetermined from your question) and that what you did was sourcing a script/pasting code and while it was running pasting another chunck of code:
What is ongoing is that you pushed data into R process input stream, it's a buffered input, so it will run each line once the previous line call has ended and free the process.
There's no easy way to play with an input buffer, that's R internal input/output system and mostly it's the Operating system which have those information in cache for now.
Asking R itself is not possible as it already has this buffer to read, any new command would go after.
Last chance thing: If you can spot your another chunck of code starting in your console, you can try pressing the esc key to stop the code running.
You may try messing with the process buffers with procexp but there's a fair chance to just make your R session segfault anyway.
To avoid that in the future, use scripts and run them on the command line separately with Rscript (present in R bin directory under windows too despite the link pointing to a linux manpage).
This would create one session per script and allow to kill them independently. That said if they both write to the same place (database, a file would create an error if accessed by two process) that won't prevent data corruption.
I am guessing OP has below problem:
# my big code, running for a long time
Sys.sleep(10); print("hello 1")
# other big code I dropped in console while R was still busy with above code
print("hello 2")
If this is the case, I don't think it is possible to stop the 2nd process from running.
I have made a Desktop shiny app for windows using the amazing package RInno but I have been experiencing some inconsistencies with launching the application. Occasionally the application will not quit its session properly, leaving R running in the background. Their github suggests using this chunk of code in the server function to insure R is properly terminated when the session ends. I can tell when the application quits properly because I include a custom function that copies the log files to a new indexed name for records and debugging.
if (!interactive()) {
session$onSessionEnded(function() {
write_logs_out() #My custom function. renames logs and stores backups of session data in .rds files
stopApp()
q("no")
})
}
In these cases a new log file is not made so I assume stopApp() and q("no") are never executed as well, leaving R running in the background. One major issue is I do not know how to reproduce this error. My current guess is that this occurs when the R session locally becomes unresponsive. While R is still running in the background, the shiny app never fully opens to a web browser. I will first need to open task manager and quit any R sessions (usually with the name "R front-end") in order to get the app working again.
Since I dont know how to expect this random error, I was wondering if any windows experts could help me write a script that will check if an R process is running, and then kill it. This would at least
I know that
tasklist | findstr Rscript.exe
will list all the current Rscripts running (which I believe is the "R front-end" i see in task manager), but I don't know if it is bad practice to simply include taskkill /IM "Rscript.exe" /F before the line that calls the .wsf file that starts the app.
The main problem I see with this is that if the session is running fine and the user for some reason clicks the app again, it will force a complete restart.
Any suggestions?
I am currently running R on a Microsoft Azure instance (Ubuntu virtual machine) using RStudio as my IDE, to which I connect simply through my browser. I am trying to run some commands that take quite some time to complete from within RStudio and figured that I could simply close my tab with RStudio open and the process would keep running. However, when I try to reconnect to see how the process is doing, the page keeps loading but I am unable to see RStudio.
I have a few questions regarding running RStudio on a server:
First, am I correct in thinking that I can close my tab and keep the process running?
Second, is it normal behaviour that I am unable to connect to the server while the process is running?
Third, am I going about this the correct way or are there better ways?
Yes, you can close your tab and keep it running.
RStudio Server waits on updates from the R process to update the UI. This means that if you have a long-running computation, your tab may not fully reload until it's finished. You may also have seen this in the middle of a session: when R is busy, you can have problems saving scripts that are open in the editor pane.
Logging out in the middle of a computation should be safe, but be aware that RStudio will save your workspace and shut R down after a period of inactivity. It then reloads everything when you log back in. But this only extends to objects in memory; if you have any files saved in your temp directory, they'll have disappeared when you come back. They're probably still on the disk, but since your new R session has a new temp directory, you'll have to do a manual search for them.
I want to execute a R script in the background from the R console.
From the console , i usually run R script as source('~/.active-rstudio-document')
I have to wait until the script is completed to go ahead with my rest of work.
Instead of this i want R to be running in the background while i can continue with my work in the console.
Also i should be somehow notified when R completes the source command.
Is this possible in R ?
This might be quite useful as we often sees jobs taking long time.
PS - i want the source script to be running in the same memory space rather than a new one. Hence solutions like fork , system etc wont work for me. I am seeing if i can run the R script as a separate thread and not a separate process.
You can use system() and Rscript to run your script as an asynchronous background process:
system("Rscript -e 'source(\"your-script.R\")'", wait=FALSE)
At the end of your script, you may save your objects with save.image() in order to load them later, and notify of its completion with cat():
...
save.image("script-output.RData")
cat("Script completed\n\n")
Hope this helps!
Sometimes, right after I submit a computation-intensive run to R in ESS, my whole screen freezes. When that happens, none of the Emacs commands work (I use laptop running XP). My crude solution is to press Control-Alt-Del, go to the Task Manager, and kill the R process, not the Emacs process. (I actually use Process Explorer). Once I kill the R process, I get the Emacs buffers back, but lose the R session. I can then do Meta-R and start again.
Does anyone know of a more graceful way to exit/abort from R within ESS?
Control-G will get you control of emacs again. Then control-C twice will interrupt R and probably get your prompt back.