[ESS] R session starts sending commands to wrong place
rsparapa at mcw.edu
Tue Jun 30 17:06:19 CEST 2009
Ross Boylan wrote:
> Short version: I have an ess-remote session (under openMPI) and a
> regular R session. Sometimes, typically after a long computation
> (hours) in the ess-remote session, commands entered in the ess-remote
> session get echoed to and executed by the regular R session. The
> ess-remote session appears hung and unresponsive during this time.
> I worked around this by quitting R in the *R* window, responding yes to
> several complaints about the R process disappearing, and then typing the
> commands in the ess-remote buffer. This time, they stayed in the
> Aside from not starting multiple R sessions, is there a good way to
> avoid this problem? Is it a bug?
> 11433 pts/4 S<s 0:00 /bin/sh
> 11530 pts/4 S<+ 0:54 \_ emacs
> 14250 pts/0 S<s 0:00 \_ /bin/sh -i
> 30209 pts/0 S<+ 0:00 | \_ mpirun -np 32 --hostfile hosts
> 30014 pts/6 S<s+ 0:09 \_ /usr/lib64/R/bin/exec/R --no-readline
> 30214 ? S<s 0:00 orted --bootproxy 1 --name 0.0.1 --num_procs
> 5 --vpid_start 0 --nodename n7 --universe ross at n7:default-universe-3
> 30215 ? S< 0:00
> \_ /bin/bash /home/ross/clean/OLTData/RMPIInteractive
> 30219 ? S< 141:09 | \_ /usr/lib64/R/bin/exec/R --no-save
> 30219 is the only R process not at 100% CPU, characteristic of openmpi
> slaves. So presumably that is where the commands should be going.
> strace showed only
> 30219 15:49:37 read(0, <unfinished ...>
> I wonder if the cause is some interaction between ESS and openmpi, which
> does some input and output redirecting to wire one of the spawned
> processes (almost certainly 30219) to my "terminal". My understanding
> is that ess-remote is simply sending commands to that terminal, and
> openmpi is taking care of getting them to the master R.
> In even more detail:
> 1. start emacs
> 2. open shell within emacs
> 3. execute the mpirun command within the shell.
> 4. They invoked script does
> R --no-save $*
> for rank 0 and
> R --no-save $* > rmpi.$RANK 2>&1
> for others.
> 5. In emacs, invoke ess-remote with language r.
> 6. In my terminal
> in an effort to avoid death at the first error.
> It does that, but R's machinery still seems to think it's
> 7. do long computation
> 8. type a command, most commonly save.image()
> 9. hit enter.
> 10. cursor sits blinking on the "(" in save.image()
> 11. terminal non-responsive to inputs, mostly (in particular, hitting
> enter has no effect)
> 12. hitting ctl-g seems to cause previous enters to print out, and
> better response to keys (at least I can switch to another session).
> Step 8 is sometimes preceded by some commands executing successfully.
> It has hung up on commands involving no obvious disk I/O, e.g., print.
> This coupled, with sys admin check that the disk is OK, suggests it's
> not a disk problem.
> The workspace (.RData) is around 13MB. It's time stamp seems to match
> when I issued the save.image() command, but that is a save from the
> regular R process in the same directory.
> I am not sure about the relative timing of launching the ess-remote
> process and the regular ess process.
> Debian Lenny
> ess 5.3.8~svn3917-1
> emacs 22.2+2-5
> openmpi-bin 1.2.7~rc2-2
> r-base-core 2.7.1-1+lenny1
Nice bug report. However, I have no idea :o) Can you upgrade these
packages to the latest version and still reproduce the bug?
More information about the ESS-help