Hi all,
Thanks for the responses. Ted - thank you for your help. I had to
laugh. I'm no computer guru, but I do know unix well enough to know
not to type "<PID>". But then again, my original code did contain a
matrix with >>2^31-1 elements, so maybe your assumption was reasonable
;)
Anyway, all your kill statements merely kill R, script included, which
doesn't really do what I'd like.
Thus, summary of responses:
Question:
"How do I interrupt an R process that's taking too long?"
Answer:
"You don't. Kill R. And don't make mistakes."
Matthew
On Mon, Mar 15, 2010 at 2:49 PM, Ted Harding
<ted.hard...@manchester.ac.uk> wrote:
> [Though I'm not using a Mac, OS X is a Unix variant and should
> have the commands used below installed]
>
> Did you *literally* do
> kill -s INT <PID>
> without substituting the R PID for "<PID"? If so, then here's a tip.
> In Mac console, do
>
> ps aux | grep R
>
> On my Linux machine this currently responds with (amongst some
> irrelevant lines):
>
> ted 8625 0.0 3.2 41568 34096 pts/6 S+ Mar13 0:07
> /usr/lib/R/bin/exec/R --no-save
>
> showing that the PID of the R process is 8625. Then you can do
> whatever corresponds to
>
> kill -s INT 8625
>
> (replacing "8625" with what you get from ps). However, when I
> just tried it, it didn't work for me either. So I changed the
> Signal from "INT" to "HUP", and this time it did work. Maybe
> try this instead?
>
> Other ways of using 'kill' include
> (a) Use the signal number (1 for HUP, 2 for INT) like
>
> kill -1 8625 or kill -2 8625
>
> (b) Don't search for the numeric Process ID (PID) but kill it
> by name ('killall' command):
>
> killall -1 R or killall -2 R
>
> However, this will kill every running instance of R (if you
> two or more running simultaneously), and you may not want that!
>
> Hoping this helps,
> Ted.
>
>
>
> On 15-Mar-10 20:20:29, Matthew Keller wrote:
>> Hi all,
>>
>> Thanks Simon and Duncan for the help. Sorry to be dense, but I'm still
>> unsure how to interrupt such processes. Here's an example:
>>
>> for (i in 1:100000){
>> a <- matrix(rnorm(100000*100000),ncol=100000)
>> b <- svd(a) }
>>
>> If you run this, R will hang (i.e., it's a legitimate execution, it
>> will just take a really long time to execute). The most obvious
>> solution is to write code that doesn't do unintended things, but
>> that's not always possible. Is there a way to interrupt it? I tried:
>>
>> kill -s INT <PID>
>>
>> and at least on Mac it had no effect. Thanks again,
>>
>> Matt
>>
>>
>>
>> On Mon, Mar 15, 2010 at 1:19 PM, Simon Urbanek
>> <simon.urba...@r-project.org> wrote:
>>>
>>> On Mar 15, 2010, at 14:42 , Adam D. I. Kramer wrote:
>>>
>>>> +1--this is the single most-annoying issue with R that I know of.
>>>>
>>>> My usual solution, after accomplishing nothing as R spins idly for a
>>>> couple
>>>> hours, is to kill the process and lose any un-saved work.
>>>> Â_save.history()
>>>> is
>>>> my friend, but is a big delay when you work with big data sets as I
>>>> do, so
>>>> I
>>>> don't run it after every command.
>>>>
>>>> I have cc'd r-help here, however, because I experience this problem
>>>> with
>>>> non-OSX R as well...when I run it in Linux or from the OSX
>>>> command-line (I
>>>> compile R for Darwin without aqua/R-framework), the same thing
>>>> happens.
>>>>
>>>> Is there some way around this? Is this a known problem?
>>>>
>>>
>>> "Hanging" for a long period of time is usually caused by poorly
>>> written
>>> C/Fortran code. You can always interrupt R as long as it is in the R
>>> code.
>>> Once you load a package that uses native code (C/Fortran/..) you have
>>> to
>>> rely on the sanity of the developer to call R_CheckUserInterrupt() or
>>> rchkusr() often enough (see 6.12 in R-ext). If you have some
>>> particular
>>> package that does not do that, I would suggest alerting the author. By
>>> definition this requires cooperation from authors, because
>>> interrupting
>>> random code forcefully (as it was possible many years ago) creates
>>> leaks and
>>> unstable states.
>>>
>>> Cheers,
>>> Simon
>>>
>>>
>>>
>>>> Google searching suggests no solution, timeline, or anything, but the
>>>> problem has been annoying users for at least twelve years:
>>>> http://tolstoy.newcastle.edu.au/R/help/9704/0151.html
>>>>
>>>> Cordially,
>>>> Adam
>>>>
>>>> On Mon, 15 Mar 2010, Matthew Keller wrote:
>>>>
>>>>> HI all,
>>>>>
>>>>> Apologies for this question. I'm sure it's been asked many times,
>>>>> but
>>>>> despite 20 minutes of looking, I can't find the answer. I never use
>>>>> the GUI, I use emacs, but my postdoc does, so I don't know what to
>>>>> tell her about the following:
>>>>>
>>>>> Occasionally she'll mess up in her code and cause R to hang
>>>>> indefinitely (e.g., R is trying to do something that will take
>>>>> days).
>>>>> In these situations, is there an option other than killing R (and
>>>>> the
>>>>> work you've done on your script to that point)?
>>>>>
>>>>> Thank you,
>>>>>
>>>>> Matthew Keller
>>>>>
>>>>>
>>>>> --
>>>>> Matthew C Keller
>>>>> Asst. Professor of Psychology
>>>>> University of Colorado at Boulder
>>>>> www.matthewckeller.com
>>>>>
>>>>> _______________________________________________
>>>>> R-SIG-Mac mailing list
>>>>> r-sig-...@stat.math.ethz.ch
>>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>>
>>>>
>>>> _______________________________________________
>>>> R-SIG-Mac mailing list
>>>> r-sig-...@stat.math.ethz.ch
>>>> https://stat.ethz.ch/mailman/listinfo/r-sig-mac
>>>>
>>>>
>>>
>>>
>>
>>
>>
>> --
>> Matthew C Keller
>> Asst. Professor of Psychology
>> University of Colorado at Boulder
>> www.matthewckeller.com
>>
>> ______________________________________________
>> R-help@r-project.org mailing list
>> https://stat.ethz.ch/mailman/listinfo/r-help
>> PLEASE do read the posting guide
>> http://www.R-project.org/posting-guide.html
>> and provide commented, minimal, self-contained, reproducible code.
>
> --------------------------------------------------------------------
> E-Mail: (Ted Harding) <ted.hard...@manchester.ac.uk>
> Fax-to-email: +44 (0)870 094 0861
> Date: 15-Mar-10 Time: 20:49:57
> ------------------------------ XFMail ------------------------------
>
> ______________________________________________
> R-help@r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/r-help
> PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
> and provide commented, minimal, self-contained, reproducible code.
>
--
Matthew C Keller
Asst. Professor of Psychology
University of Colorado at Boulder
www.matthewckeller.com
______________________________________________
R-help@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-help
PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
and provide commented, minimal, self-contained, reproducible code.
