I am using emacs-snapshot with the ssh.el package, following the instructions from the ess manual.
There are a few ways to open an R session, but this is how I do it:
open emacs
C-x C-f /server:dir/file.R this puts me in ESS [S] mode
Type 'plot(1)'
C-c C-n to run
emacs asks for starting directory, and I choose the /server:dir/
I would like for a figure to pop up but it wont.
This also doesn't work when using ess-remote in shell or tramp mode, but it does work if I set the starting directory to my local desktop.
Any advice much appreciated. My current workaround is to print the file to pdf and then open pdf in DocView mode, but this takes a few extra steps and is slow.
I do it the other way around:
ssh -X some.server.com to connect to a remote server with x11 forwarding.
emacsclient -nw to restart an Emacs session that is already running
plot(cumsum(rnorm(100))) in R as usual
Then the plot windows appears on the initial machine I ssh'ed away from.
Edit: As a follow-up to the comment: This works for any emacs, either emacs or emacs-snapshot. For a long time I used (server-start) in the ~/.emacs but now I prefer that (just once) lauch emacs --daemon after which I can then connect to via emacsclient (which also exists as emacsclient-snapshot). I really like this -- it gives me Emacs around R in a persistent session that I connect, disconnect and reconnect to.
I selected Dirk's answer because he pointed me in the right direction, and especially for lowering the energy of activation required to visualize my data, but here I am going to give the details of how I got this to work on my desktop.
1) set ssh keypairs (I had previously done this, full instructions for Ubuntu here)
mkdir ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t rsa
ssh-copy-id username#hostname
2) include the following in ~/.ssh/config
Host any_server_nickname
HostName hostname
User username
ForwardX11 yes
3) open emacs on local machine
4) C-x C-f
5) /any_server_nickname:dir/file.R for files in home directory or /any_server_nickname:/path/to/file.R
6) plot(1)
7) C-x C-b to evaluate entire buffer.
Related
I am trying to run bad blocks on macOS High Sierra 10.13.6. I installed bad blocks using macports. I keep encountering errors when attempting to run it and I am not sure how to even get bad blocks running
sudo badblocks -c 4096 -s -w -o /Users/mcbeav/Desktop/blocks.txt /dev/disk0s2
This keeps returning the error
badblocks: Resource busy while trying to determine device size
If I try
sudo badblocks -c 4096 -s -w -o /Users/mcbeav/Desktop/blocks.txt /dev/disk0
I get the error
badblocks: Value too large to be stored in data type invalid end block (7813820416): must be 32-bit value
Can anyone please help me out?
My recommendation is that you:
a) Run badblocks via the Mac OS X console in Recovery Mode
High Sierra (10.13+) along with APFS (file format system) prevent certain operations on disk. You'll have to be in recovery mode or turn off disk protection to do as you propose.
Turn off your Mac (Apple > Shut Down).
Hold down Command-R and press the Power button. ...
Wait for OS X to boot into the OS X Utilities window.
Choose Utilities > Terminal.
Enter csrutil disable.
Enter reboot.
Mac OS X Workaround:
My sense from past experience is that you are hitting the MacOSX security features (Disk protection and app certification).
Booting to Ubuntu (USB Stick) and running the badblocks test that way is going to be easier. (In my opinion)
I hope this points you in the right direction.
I had the same issue. But then I opened Disk Utility and pressed Eject on the physical device (make sure it's the hard drive and not the volume). This will unmount the volumes but will keep the device still available, which you can check by running:
diskutil list
Now run the badblocks command again and it should work fine.
I was able to get badblocks working for OSX 10.15 by
1) disabling csrutil, as explained here
2) unmounting the badblock-desired drive via Disk Utility
3) running badblocks: sudo badblocks -b 4096 -w -s -v "$MOUNT_POINT" > "badblocks.info", where MOUNT_POINT=/dev/disk2
I installed badblocks via brew install e2fsprogs, as described here
Tangentially, I also did this in order to query the USB-connected drive via smartctl.
Working in R 2.14.1, on Windows 7
Using the package parallel in R, I'm trying to take advantage of cores outside of my local machine available on my network, where all remote hosts I am connecting to are identical Windows machines.
The basic form of the commands are as such to make the connection.
library(parallel)
#assume 8 cores per machine
cl<-makePSOCKcluster(c(rep("localhost", 8), rep("otherhost", 8)))
Of course, trying to debug these things can be pretty tricky, but here is where I'm at with it.
If I specify the manual = TRUE flag as below
cl<-makePSOCKcluster(c(rep("localhost", 8), rep("otherhost", 8)), manual=TRUE)
there are no problems connecting to the remote host, and running a parallel process. The computers have identical setups to the one that I am working on. Yet, when this manual flag is not set, the connection command hangs.
This seems to indicate to me that since the manual flag bypasses ssh to make the connection to the host, that ssh is the problem when manual=FALSE.
It is not guaranteed at the moment that the remote computers have ssh on them. The question is, given that I have all the pertinent windows login information for my remote hosts, and that I cannot change the settings on the remote computers, how would I connect to cores on remote machines with the package parallel in R without specifying manual = true?
Alternatively, if ssh must be installed for this to happen, let's assume all computers have ssh on them. How would I connect to cores on the remote machines without circumventing ssh?
If you need any more information please let me know, I appreciate the time.
UPDATE 1
8-26-14
Thanks to Steve Weston for his insights. I will provide an update with the exact tools and setup I use to get my system working when it's up and running.
Feel free to comment or post if you have anything else to add as to what may be the best route to go in remote connecting to a windows machine from a windows machine via makePSOCKcluster, where the manual flag is set to FALSE.
When creating a PSOCK cluster with manual=FALSE, the only way to start a worker on a remote machine is with "ssh", "rsh", or something command-line compatible, such as "plink" from PuTTY. The reason is that makePSOCKcluster starts the remote workers using the "system" function to execute commands of the form:
ssh -l user otherhost '/usr/lib/R/bin/Rscript' -e 'parallel:::.slaveRSOCK()' MASTER=myhost PORT=10187 OUT=/dev/null TIMEOUT=2592000 METHODS=TRUE XDR=TRUE
You can confirm this by looking at the source code for the newPSOCKnode function in the file snowSOCK.R from the parallel package.
For this to work, the ssh-compatible command must be available on the local machine and a corresponding ssh daemon must be running on each of the remote machines, otherwise makePSOCKcluster will simply hang. I've found that installing a good, working ssh daemon is the difficult part on Windows.
Unfortunately, manual=TRUE is generally the easiest way to create a PSOCK cluster on multiple Windows machines.
Helle everyone, I had the same problem and I managed to solve it. It is June 2018 when I'm writing this answer, my OS is windows 10 and the R version is 3.2.2. It is surprising to see this problem still exists after 4 years. I hope it can be fixed in the following release.
Before you move on, please make sure you can access the server in cmd using ssh. I didn't put any password in my code because I have the private key, you don't need to do that and you will see the reason later.
Fixing The problem
File directory
Since the function makePSOCKcluster works when manually start the workers, my first trying is to let manual=TRUE, and see what's the output. Here is my result:
machineAddresses <-list(list(host='192.168.1.220',user='jeff'))
cl <- makePSOCKcluster(spec,manual = F)
> Manually start worker on 192.168.1.220 with
"C:/PROGRA~1/R/R-32~1.2/bin/x64/Rscript" -e
"parallel:::.slaveRSOCK()" MASTER=DESKTOP-U5JA32O PORT=11756
OUT=/dev/null TIMEOUT=2592000 METHODS=TRUE XDR=TRUE
Ok, Here is the first problem. The Rscript location is incorrect(The location of Rscript in the server). Generally, it locates in C:\Program Files. In my server is C:\Program Files\R\R-3.2.2\bin. So we need to correct them by adding more option to tell this stupid code where the Rscript is:
machineAddresses <-list(list(host='192.168.1.220',
user='jeff',rscript="C:/Program Files/R/R-3.3.2/bin/Rscript"))
CMD problem
Once you fix the directory problem, you will find that the code still hangs forever. Then we need to check if we can manually access the server in R, my code is:
system("ssh jeff#192.168.1.220")
> GetConsoleMode on STD_INPUT_HANDLE failed with 6
I honestly don't know what does this error mean, but we just need to fix that. Inspired by #Steve Weston, I decide to use PuTTY, so I install it, and change my code to:
machineAddresses <-list(list(host='192.168.1.220',user='jeff',rscript="C:/Program Files/R/R-3.3.2/bin/Rscript",rshcmd="plink -pw qwer"))
The option -pw means the password. Because I'm a newbie to PuTTY, I don't know how to let the private key automatically work in PuTTY. Therefore, I use the easiest way to deal with that: put your password! The above code is equivalent to the following in cmd:
plink -pw qwer jeff#192.168.1.220 Rscript -e parallel:::.slaveRSOCK() MASTER=DESKTOP-U5JA32O PORT=11063 OUT=/dev/null TIMEOUT=2592000 METHODS=TRUE XDR=TRUE
And this is exactly what we will do if we manually create the workers. For those who are new like me, you need to add the PuTTY directory in PATH in your environmental variables to run plink. Here are my final codes:
machineAddresses <-list(list(host='192.168.1.220',user='jeff',rscript="C:/Program Files/R/R-3.3.2/bin/Rscript",rshcmd="plink -pw qwer"))
cl <- makePSOCKcluster(machineAddresses,manual = F)
I run it with no problem at all. In summary, the function makePSOCKcluster makes two mistakes:
Assuming a wrong R directory in the server(At least it should assume the same directory as my local computer, but it didn't! I don't know where that strange directory comes from)
Using ssh command to start the connection, which does not work in R. It works well in cmd, but not in R. I don't know the reason.
If you are still not able to use makePSOCKcluster, here is one trick: Try to connect to the server in R using system function first. It can give you some error code, that may instruct you where the problem is. Here is my debugging code:
system("plink -pw qwer jeff#192.168.1.220 Rscript -e parallel:::.slaveRSOCK() MASTER=DESKTOP-U5JA32O PORT=11063 OUT=/dev/null TIMEOUT=2592000 METHODS=TRUE XDR=TRUE")
Is it possible to export/import tmux sessions?
At the university we have identical machines (same binaries and file structure) and sometimes I want to move a tmux session from one machine to another. Is there a way to do this?
As pointed on the comments, it is very unlikely that you would be able to restore all the state of tmux session.
If your purpose is to access the tmux session from a different machine (hostB), while the tmux session is still running on the original machine (hostA), you could simple access it through ssh:
hostB $ ssh hostA
hostA $ tmux attach
The link you mentioned contains a discussion about how to re-create a tmux session. If you are interested in starting a similar tmux session, you should try tmuxinator:
# ~/.tmuxinator/sample.yml
name: sample
root: ~/
windows:
- editor:
layout: main-vertical
panes:
- vim
- guard
- server: ssh serverX
- logs: tail -f log/development.log
By issuing mux start sample you will have a tmux session with three windows:
the first with two panes, the first one running vim
the second with a ssh to a given server
the third displaying the tail of a log file
Using this file you could start similar sessions on different machines.
i was created a bash script my_vp.sh that use 2 command:
setterm -cursor off
setterm -powersave off
[...]
#execute video commands
[...]
and is in a computerA
but when i execute it by ssh by another computerB_terminal:
ssh pi#192.168.1.1
execute video commands work correctly in the computerA (the same where is the script)
but the command setterm works in the computerB (the terminal where i execute the ssh command).
somebody can help me with solucione it?
thank you very much!
I am not sure I understood the question:
to execute a local script, but on another machine:
scp /path/to/local/script.bash pi#192.168.1.1:/tmp/copy_of_script.bash
and then, if it's copied correctly, execute it:
ssh pi#192.168.1.1 "chmod +x /tmp/copy_of_script.bash"
ssh pi#192.168.1.1 "bash /tmp/copy_of_script.bash"
to have the remote video (Xwindows, etc) commands appear on the originating machine:
replace : ssh with : ssh -x (to allow X-Forwarding, which will allocate a DISPLAY automatically on the remote machine that will be tunneled back to the originating machine)
for the X-forwarding to work, there are some requirements (usually ok by default, but ymmv) : read more about those requirements in this Unix.se answer
I am currently in a byobu-tmux session and am ssh'ed into a screen session. How do I detach the remote screen session without detaching byobu-tmux session? Some things to note, I can't run byobu-config because I'm on osx and don't have python-newt (w/ snack) installed. And, I've run byobu-ctrl-a in Emacs mode, but that doesn't seem to allow me to ctrl-a d out of the remote screen session.
It is easy when you use tmux commands:
byobu-tmux detach
byobu-tmux
or even just:
byobu detach
byobu
You should be able to double-escape with Ctrl-a.
To send a detach message to the inner byobu-screen session, press:
Ctrl-a Ctrl-a d
Full disclosure: I am the author and maintainer of Byobu.
Try letting go of ctrl after the first a, so the sequence is ctrl-a, a, d. Man screen:
C-a C-a (other) Toggle to the window displayed
previously. Note that this
binding defaults to the command character typed twice, unless
overridden. For instance, if you use the option "-e]x", this
command becomes "]]".
C-a a (meta) Send the command character (C-a) to
window. See escape com‐
mand.
Or if you're using tmux instead of screen for Byobu, try just ctrl-a d. Byobu's default prefix key is ctrl-b, so if you're using that default, doubling up the ctrl-a keystroke would not be necessary.
Source: https://askubuntu.com/a/309215/106100
I was able to do this by listing all clients inside the current client:
$ byobu list-clients
/dev/pts/67: 1 [80x24 xterm] (utf8)
/dev/pts/70: 1 [157x48 xterm-256color] (utf8)
Then detach the remote client (determined based on screen size):
$ byobu detach -t /dev/pts/67
Now I can use my full window size
perhaps not relevant to tmux but for byobu, I found the following command to be very helpful: detach all sessions except the current one:
/usr/lib/byobu/include/tmux-detach-all-but-current-client
hope this helps
You need to switch the prefix of your local session if it conflicts with the remote session. For example, if both are using CTRL+A then you'd be in trouble. You can either send a raw command (there's a sequence for that, but I can't remember it), or go the easy route and remap your local session to Ctrl+B, then you can input Ctrl+A that will get routed to the remote session. Also not related to tmux but the ssh connection itself you can input "~." and it'll disconnect from the ssh session. Hope it helps.
I've been an avid user of byobu on Linux for the best part of a decade. After struggling with configuring the brew install of byobu on OSX for most of these years, I finally managed to setup my byobu configs in a round about way. First I executed this:
echo '/usr/local/lib/python2.7/site-packages' | sudo tee /Library/Python/2.7/site-packages/homebrew.pth
Then I ran the byobu config file:
byobu-config
Finally I cleaned up
sudo rm /Library/Python/2.7/site-packages/homebrew.pth
Python crashed along the way with a few pop-ups, however, byobu now works for me as it should. I do need to repeat these steps when I want to change config again though... still looking for a cleaner solution.