I have a script in bash, running multiple PuTTY sessions.
For example, I open the connection to run a couple of commands, when it finishes it saves the values, closes the session, opens a new session and runs a couple more.
This script is supposed to run for 60 hours, more or less, so i need to have everything automated.
My issue is, when the PuTTY session is open, and connected to the device i need, if at some point the device reboots (don't know why it reboots, it just does), a window in putty appears saying the connection was terminated (obviously). The problem is that the window stays open until I press the "ok" button. So my script just stops there until some manual interaction with the PuTTY session.
Is there a way to automatically terminate the PuTTY session if a disconnection happens?
Thank you for your help, if you need some more information just let me know!
regards
PuTTY is not intended for automation.
Use PLink (PuTTY command-line tool). It's a console application, with the same command line arguments as PuTTY, so the transition should be easy.
Though setting "Close window on exit" to "Always" does work (even if you claim it does not).
See the "Close Window on Exit" option in the Session panel.
Documentation
Related
I am using Vim inside tmux over an ssh connection on a remote machine. I access the remote server from several locations including work and at home. This usually causes stale $DISPLAY variables and associated problems, most of which I have resolved except for one:
If I have a vim session already opened, is there a way to change which X server it is connected to without closing and re-opening it? I need to be able to do this so I can copy snippets of text from Vim using the X clipboard. I normally keep multiple vertical splits, linebreak and line numbers on, so doing this through tmux is usually a giant hassle and would prefer to do it with vim.
You can use xpra to display a running X11 program (specifically, vim) on different X11 servers.
This program functions for X11 programs like GNU screen or tmux do for terminal programs. xpra provides an X server for running programs and itself acts as an X client for the X server for the user's display.
You mention that you are running vim through tmux; you should maybe run vim outside of tmux and use xpra directly. As far as I know the program has to be run through xpra from the start.
There's a relatively new command called xrestore which does this:
:xrestore :0
https://groups.google.com/g/vim_dev/c/G54XTJHAqXI
https://github.com/vim/vim/issues/3649
If the sole purpose of using X is to transfer large amount of text, consider using scp instead.
From within vim mark the lines you're interested in and do :w /tmp/foo
From a shell (or suspend vim using ctrl-z ; bg) do
scp your_username#remotehost.edu:/tmp/foo /some/local/directory
I added the following line to ~/.tmux.conf on the server and reloaded the tmux sessions there. This one-liner does the trick of automatically attaching to the local X-server when I connect to the tmux-session from multiple local clients using SSH. Each local client has its own X-server (X410 in my case).
set-option -g update-environment " DISPLAY"
How it works? According this post, the line is supposed to refresh the $DISPLAY variable for all panes. Here is another related post.
Setup: all my local clients are Windows 10 machines, running WSL (Pengwin distro as WSL2). My X-server is X410 downloaded from the Windows Store. The server that hosts the Tmux+vim sessions is a Linux Mint machine. On the server, the Tmux version is 3.3a.
Per my workflow, this means a lot. Especially that I don't have to repeat the following procedures: 1. SSH from another local machine; 2. Finding that clipboard won't work; 3. Save the work, exit Vim; 4. Start a new pane in the current Tmux session, and 5. Start Vim again, trying to load back to where I was.
I want to script opening chromium in kiosk mode under Linux (openSUSE 12.3) and XWindows, while controlling which monitor chromium appear in. I also need to have this script be run outside of a standard xterm, e.g. via ssh into the machine where chromium AND the display will run (i.e. I want the application to appear on one of the displays of the machine I'm connecting to, not the machine I'm connecting from).
I can do everything I want by hand in xterm on the target machine, but I won't be running these scripts in xterm. Somehow, the xterm environment is special: it knows how to talk to the containing XWindows session, and in fact knows which actual monitor it is hosted on. For example:
When I ssh into the machine and try to run an XWindows GUI on the target machine's display, it (reasonably) complains "Can't open display". However, even when I set the DISPLAY environment variable to the same value I see in xterm, I still get the error (although it now includes the current DISPLAY value). I've also tried setting DISPLAY to a variety of permutations on ":X.Y", where X and Y are small integers, but again to no avail.
If I run chromium in --kiosk mode from xterm, it takes over the monitor that currently contains the xterm window. If I drag xterm to my other monitor then chromium will launch in that monitor. I want that control when I launch chromium from my script, but can't figure out the background magic.
For window manipulation, I've seen suggestions to use wmctrl or devilspie, but I'm a bit nervous about depending on tools that haven't been updated in years. I'd also prefer to have chromium launch in the right place right off the bat, rather than having it appear in the wrong place and then be moved. And neither app can help me launch the app remotely.
So, here are the questions. First, how does xterm tell chromium how to connect to the right XWindows session and monitor? Second, how do I simulate that from a completely separate ssh connection? (Again: it's more than just the DISPLAY variable.)
Thanks,
Dan
You can't open X client on the target machine's display because of permissions: not anyone that can ssh into a machine may "take ownership" of it's screen. These are things controlled by xset -- read up on it.
As for the display: I assume that the specific monitor is controlled by the second part of the DISPLAY environment. At least that's what I remember from reading about X. I've never actually worked in a multi-monitor X environment.
Xterm is not special. Your mouse pointer is. Chromium will appear on the monitor your mouse pointer happens to be in. This is probably the default behaviour of your window manager.
Chromium does not respect the usual window position requests. You cannot tell Chromium where to appear, you must tell your window manager where to place the Chromium window. Methods of doing that, if they exist, totally depend on what window manager you have.
If you ssh to your machine as the user that has started the X session, you should have no problem connecting to that session.
We have Eclipse setup as our IDE on a central Linux server. Everyone will connect to the server, opens an Eclipse instance, work on it.
Eclipse will be run as a background process, showing the GUI to the user.
What happens is, sometimes people disconnect from the SSH session abruptly(making the laptop to sleep ..etc), without properly closing eclipse, which sometimes leaves the Eclipse process running in the background.
Whenever the user tries to connect next time, they are unaware of the existing Eclipse sessions, and continue starting a new one, while the existing Eclipse processes continue running in the background taking up all the resources.
Question is, can we re-connect to that abandoned Eclipse session somehow? Is it possible to bring up the Eclipse in the same state where user left it?
I looked at GNU screen . However, it can't bring the GUI application back to the user.
This seems to be a problematic setup to me. Why not work on the local computer in the first place? But if you want (or have to) to work on the server, better start the desktop directly on the server via XDMCP, VNC, or Citrix XenAPP (commercial).
EDIT: Just found this article about xmove. I haven't heard about it before, but maybe it works.
I'm accessing through ssh to a linux box. I was simply updateing the packages with yum update. I then disconnected but when I connnected again with ssh using the same account I couldn't now if the update process had already finished.
How can I know the status of tasks I've started before disconnecting when I reconnect to the server?
Thanks in advance
Use screen <program>. At this point you can either disconnect or hit CTRL-A, CTRL-D and do other things. You can later re-attach your session to the screen running your program by screen -r.
Specifically if you want to save the state of your shell between ssh sessions you can just run screen and then run your programs.
I have what is probably a very simple terminal related question.
I'm running Ubuntu 8.10 Intrepid Ibex, using Gnome, and I often open a terminal-based
ssh session only to have it dropped at some point later on. Once the session is dropped the
terminal becomes unusable, obviously because the network connection has been dropped.
Is there a way to re-initialize the session, or even revert to a working local terminal?
Under Windows, using putty, when this happens I can right-click and select restart session,
and do not need to open a new terminal, however under linux my lack of understanding on this
subject has lead me to always close the defunct terminal, and restart a new one from scratch.
I'd like to learn a new and useful trick if there's one out there.
Also, I found the following post which is worded very similarly to mine,
Automatically (or more easily) reconnect to a screen session after network interruption
reconnect-to-a-screen-session-after-network-interr
however, as far as I can tell, this is a different topic.
You want to use your SSH escape. By default it's '~', and ~. will terminate your connection.
The question you linked to is about screen, which is useful for resuming your remote session once you use the escape character to kill your local ssh process and reconnect.
First use ~. to disconnect your ssh connection locally. This gets you back to a working local terminal. You could also you another terminal to kill the appropriate ssh command.
In order to keep your remote state you should use screen as previously suggested.
I recently found out about mosh which is a interesting UDP-based resumable shell client. It uses ssh to initialise the connection, and probably needs mosh installed at the server (and UDP access between the client and server), however it can recover from disconnections and IP changes of the client.
To have your local terminal usable again, you can use the reset command.
To run a command in a virtual terminal you can attach/dettach you can use screen or tmux. Typical usage for screen:
$ screen -S somename
screen$ some-console-command
...
^ad
You detach from screen by typing ctrl+a then d
Then you can list the session and attach to it
$ screen -ls
$ screen -dr somename
screen$