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.
Related
Build: Server with Ubuntu 18.04 in data center with Ubuntu Mate Desktop interface.
As I understand, any GUI app needs a display in which to function. I connect to the server via x2go to display the ubuntu mate interface.
Once connected, I have a scheduled cron job that launches a terminal, a GUI and some commands.
Everything works perfect as I have previously detected what display I'm using as a user and specify that to launch the terminal and the commands.
Problem: if I'm not connected via x2go client to the server and provide that display, I noticed today that the cron job didn't launch at the specific time (08:50), which was previous to my x2go client connection (09:23); it just launched when I did the x2go client connection from my desktop manually -- my understanding is that it didn't launch because there was not any available display.
I'm not technical enough to get more deep into this problem.
¿Is there anyway in which I can make the cron script function (i.e. that it launchs the terminal and the GUI) without the need of manually getting into my desktop and launching the remote desktop client (x2go)?
My ideas go for having another minimal setup in that data center or another that takes the advantages of being there and have a physical monitor to display constantly connected to the main server OR just manually entering the server via x2go every day.
EDIT: When I disconnect the x2go client session from the server, the launched GUI and etc perfectly maintains, without dissapearing because "I have terminated the session and eliminated the display".
Finally got it working with the great help of one of x2go founders (Oleksandr Shneyder) after understanding how x2go handles the sessions and the X server.
Sessions can suspended/hibernated, disconnected and terminated.
Suspended/hibernated: when "manually" or automatically the x2go server side suspends so that it saves resources.
Disconnected: when you exit the session window and the x2go client in your desktop/laptop.
Terminated: when you log out from the DE environment or issue the x2goterminate-session command in the terminal inside the session.
My x2go app was somehow entering into suspending mode in the server, causing that the display (50 in my case) in which the scheduled cronjob need to be run and launche the GUIs, "was not awaken" until I entered into the session via the
app. In that moment, the cronjob started executing.
To tell x2go server to not hibernate, I needed to change the X2GO_NXOPTIONS in /etc/x2go/x2goagent.options to X2GO_NXOPTIONS="sleep=0"
After this, everything functions perfectly in the server.
Hope it helps others.
I was running gdb over an SSH shell. After a while the shell disconnected due to being idle. On reconnecting I see the gdb instance still running.
How do I take control of the running gdb instance?
Can I start a new gdb instance and take over the session from the running gdb instance?
Note: This is not about keeping the SSH session alive. This is more about taking control of gdb from another shell instance. Regardless of whether it is running from SSH or locally.
You probably can't do anything with the gdb that is already running. It probably no longer has a controlling tty at all. What you probably want to do is kill it and then start a new gdb process, but do it inside a program like tmux or screen. If you do that, then if/when you get disconnected you can easily reattach to the tmux/screen session any time. Just check out the manual for those programs. They do pretty much the same thing. I think tmux is a little more powerful.
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'm pretty new to linux...
I was running an install script for something on my ubuntu vps and I got disconnected from the server. I'm able to log back in again but I'm worried this install script might be waiting for prompts in the background.
What's the best action to take in this situation? Should I just run the script again, or should I do some kind of cleanup first?
Thanks
When you disconnect (from the terminal), the install script receives a signal (SIGHUP) which usually leads to program termination. If it is stuck, you probably should kill and re-run it, but there is no 100% confidence it will work.
Next time use screen. If you disconnect, you can then reconnect to the running screen instance using screen -dr. It has many other features you can read about in the manual or numerous tutorials.
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$