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$
Related
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
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.
For capturing ssh sessions I use "script" command: "script -c 'ssh user#host' outfile". But I have no idea how to capture sessions to remote hosts, that connected over com(serial) port.
screen script -c 'screen /dev/ttyS0 57600' file
ends immediately with empty log. Both 2 functions that implemented in screen is necessary: ability to switch between opened sessions and ability to perform i/o to /dev/ttyS. I started develop some tiny utility to redirect stdin/stdout to /dev/ttyS but now it's so buggy and doesn't work yet.
First off, a terminal program, like minicom (or good-ol cu), as suggested by Laszlo, is needed to communicate with the remote system. Once you can get such a program to work, then screen can be brought into the picture. Note that this also requires a getty running on the remote computer's serial port. If it's an old-fashioned serial port, you may also need a special null-modem cable.
Screen can be used with such a connection to be able to move access of the session across terminals. However, it cannot be used to spawn more than one session with the remote server. That's because the program running on the serial port (getty) only supports a single session. In this case, the screen runs on the local machine, and the terminal-program session running within screen connects to the remote server. So, it is possible to have multiple screens, but just not more than one connected to the remote server over a single serial port.
With all of that said, serial ports can be used to network two machines, assuming both support the same serial-line networking protocol. Networking eliminates these restrictions.
To open an interactive terminal session to a COM port (/dev/ttyS*), you probably want to use a terminal emulator software, like 'minicom'.
I am having some problems with launching firefox from a Linux daemon written in C.
When I launch firefox on the machine itself (via terminal) from the command shell using /usr/bin/firefox it works OK and a firefox browser window lanunches as it should.
However if I try this within my C daemon using system("/usr/bin/firefox"), firefox launches its process in the terminal but the browser window is not opened?
A similar thing happens when I try to do this using remote terminal acces. It's something to do with telling the system to open firefox in window mode rather than trying to open it in terminal mode - but I dont know how to specify this using bash commands?
I am using Lubuntu 11.10 in my Linux System.
Any help is most appreciated.
There's a reason I asked why you're attempting to do what you want. I didn't want to get into great details in my comment.
Firefox on Unix is an X-Window process (most of the Linux/Unix desktops are based upon the X11 protocol which is the heart of X-Window). What X-Window does is separate the display of the program from the process running the program. For example, I am now running Firefox from a Linux box at work, but the Linux box is actually displaying the Firefox browser window at home on my Mac.
In order to do this, I had to:
Run X11 on my Mac. The X11 program creates a default X11 client display called 0.0 which pretty much says the first screen and the first instance of X11 running (computer geeks like counting from zero). The process runs in the background on my Mac. In a certain sense, it's really a server process and not a client because it's waiting on port 6000 for a client X11 process (Firefox) to tell it what to do.
Before I run firefox, I have to tell my Mac's X11 process that I grant the X11 server running Firefox to be able to display on my X11 client process. Otherwise, you can imagine someone spamming another person by continuously popping up Windows on their display. You can use the xhost program to do this.
In order to run Firefox on the Linux box, I have tell the Firefox process what X11 client I'm running it on. I can do this by setting the DISPLAY environment variable to something like "10.0.1.33:0.0". This means the X11 client is running the the machine on IP address 10.0.1.33, and I want you to use the first screen, and the first instance of the X11 client on that screen.
Now, I can run Firefox on my Linux box, and the display will display on my Mac.
The problem you're running into is that there's simply no X11 client when you're starting FireFox as a daemon process. An X11 client is associated with a user and a display of some sort. The display could be a virtual display, but there's got to be an X11 client that's running and is addressable in some way, so the process knows where to display the output.
By the way, you said daemon which has a very, very specific meaning in Unix/Linux. A daemon is a process that runs in the background and usually has a service (and a port) associated with it. For example, there's an FTP daemon called ftpd, the mail server uses the sendmail daemon, ssh has the sshd daemon. Daemons have no display associated with them.
However, it looks like you might be using the word to mean launching Firefox via another process. Is that true? If so, you'll have to make sure that Firefox knows the X11 display to use (there's a command line setting to use to specify the display), and that your X11 client (your login session) has given permission for another process to update your display with the program window.
Can you please explain what you're trying to do in a bit more detail? If you simply want to download a file from a remote http server (which of course is running the http daemon process called httpd), you should use curl or wget which don't require a display and are way simpler to use. If you're trying to do something else, let us know exactly what it is.
Firefox needs to know which display it should open on. When you run it from within a gui, even through a terminal emulator, the DISPLAY environment variable is set to the appropriate value. When you launch from the daemon, try system("/usr/bin/firefox -display=:0").
Make sure that the DISPLAY environment variable is properly set in your daemon to refer to the X server that you want your firefox to use.
If the daemon is run as a different user account than the user account that "owns" the X server that you want to use, you will also need to use xauth(1) to configure the authentication token to grant permission to use the X server.
Often times, it is far easier to use ssh -X to tunnel X and properly configure the xauth(1) tokens in one go than try to manage xauth(1) tokens yourself. Maybe adding ssh -X into your environment would be suitable, maybe not. (I've even used ssh -X root#localhost before when I needed to run an X client as root and didn't want to bother with configuring xauth(1) manually. ssh(1) is just so much easier.)
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.