My server disconnected; how to reach back to the same open terminal?

ravisingh1 · 09-07-2013, 07:17 AM

I was installing ubuntu-desktop on my remote server (VPS).
But unfortunately the connection got disconnected.
(I had connected via ssh)
I think the process on the remote server has stopped waiting for my input.
It was asking for my input regarding blutooth.conf.
I am copying below where the process (of installing ubuntu-desktop) got stuck.
Below is output as seen in the terminal:
---------------------------------------

Code:

Setting up appmenu-gtk:i386 (12.10.3daily13.04.03-0ubuntu1) ...
Setting up libdbusmenu-gtk3-4:i386 (12.10.3daily13.06.19~13.04-0ubuntu1) ...
Setting up appmenu-gtk3:i386 (12.10.3daily13.04.03-0ubuntu1) ...
Setting up libdaemon0 (0.14-2build1) ...
Setting up avahi-autoipd (0.6.31-1ubuntu3) ...
Setting up bluez (4.101-0ubuntu8b1) ...

Configuration file `/etc/init/bluetooth.conf'
 ==> File on system created by you or by a script.
 ==> File also in package provided by package maintainer.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** bluetooth.conf (Y/I/N/O/D/Z) [default=N] ? Write failed: Broken pipe
ravbholua@ravbholua-Aspire-5315:~$

Now when I again tried to connect via ssh, it took me to a new terminal (I suppose). Any way so that I can go back to the previous terminal and type my reply so that the installation w'd complete.

Just a general question: Once disconnected , is it possible to go back (after reconnection) to the previous terminal where I left. If no, then how w'd a user proceed ahead if the remote terminal (is it remote terminal or local?) awaits for user's input and the user got disconnected.

dt64 · 09-07-2013, 07:29 AM

I don't know about the Ubuntu remote setup using SSH, but on an installed and running server you could always use nohub or, preferable, screen. This would allow running programs to continue even your session got disconnected and you could connect back any time.

screen gives you other possibilities as well, e.g. session sharing...

grabie2 · 09-07-2013, 07:32 AM

Hello,

EDIT: dt64 was first...

After you disconnected and after the connection timeout ended console was probably killed, so you can't really connect to the same terminal.

As far as I know all terminals are in /dev/pts/x. You should check(using `ps`, `top, etc.) if the apt process is still running in background, if so then check it's terminal(it should be listed in `ps aux` output). But I don't know any program that can connect to another terminal.

In future you should use `screen`.
From Wikipedia:

Quote:

GNU Screen can be thought of as a text version of graphical window managers, or as a way of putting virtual terminals into any login session. It is a wrapper that allows multiple text programs to run at the same time, and provides features that allow the user to use the programs within a single interface productively. This enables the following features: persistence, multiple windows, and session sharing.
Screen is often used when a network connection to the terminal is unreliable, as a dropped network connection typically terminates all programs the user was running.

When connection is interrupted screen still runs in background and you can reconnect to that terminal.

I hope that helps a little.

Regards,
Bartek

ravisingh1 · 09-07-2013, 08:31 AM

Quote:

Originally Posted by grabie2

After you disconnected and after the connection timeout ended console was probably killed, so you can't really connect to the same terminal.

Oh! I didn't expect that. That means if I get disconnected and after the timeout ends, console gets killed. And as console is killed the process which is running (in foreground obviously) also gets killed??? Is it so?

What I had a wrong thinking that : I am working on local machine. Now I connect to remote server and run any process (for example installing any program like ubuntu-desktop). I used to think that I can get disconnected (locally) from internet and the server process w'd run as it has it's own internet.
Oh! a great revelation!!

But it seems that "screen" can come here as a rescue. And with 'screen', I can get disconnected locally and not to bother of remote as the processes w'd always run until finished.

273 · 09-07-2013, 08:49 AM

Remember to run screen on the remote machine though. Apologies if that's stating the obvious but I thought it worth mentioning just in case.

ravisingh1 · 09-07-2013, 09:16 AM

@273
Thanks for mentioning it.

273 · 09-07-2013, 09:21 AM

Quote:

Originally Posted by ravisingh1

@273
Thanks for mentioning it.

You're welcome. I didn't think it was immediately obvious from just reading about screen but the screen process basically holds the terminal open on the remote machine so you can reconnect to your screen session. It has split-screen functionality and some other cool things as well.

ravisingh1 · 09-07-2013, 09:50 AM

Quote:

Originally Posted by 273

I didn't think it was immediately obvious from just reading about screen

Yes, I read the wiki page of screen but it wasn't clear as how to run.

Quote:

Originally Posted by 273

Remember to run screen on the remote machine though

Good you mentioned this but please elaborate a bit.
Remotely, when I am in a terminal, so the 1st thing should be to run

Code:

screen

Now, if i run another terminal or close the 1st one, then again I don't need to run

Code:

screen

That means, only once anywhere I should run it. Is it O.K.?

273 · 09-07-2013, 10:01 AM

From the terminal of your local machine, a session using screen would go something like:

Code:

me@localmachine:~$ssh remote.machine.com
<enter username and/if password as necessary>
me@remotemachine:~$screen
<screen then announces itself (you can turn the message off>
me@remotemachine:~$wget aremotefilewhichwilltakehourstodownload
Ctrl+a d
me@remotemachine:~$exit
<remote machine says goodbye>
<some hours go by>
me@localmachine:~$ssh remote.machine.com
<enter username and/if password as necessary>
me@remotemachine:~$screen -x
<find wget has finished>
me@remotemachine:~$exit
<ends screen session>
me@remotemachine:~$exit
<logs off remote host>

grabie2 · 09-07-2013, 10:03 AM

To start a new screen session you run:

Code:

screen

or(if you want to work with multiple screens

Code:

screen -S <name>

to list all open screens:

Code:

screen -ls

to reattach to detached screen:

Code:

screen -r [name]

to attach to already attached screen(sometimes it happens whe your connection drops, or if you work with multiple people on one screen)

Code:

screen -x [name]

to detach from screen, to leave it running:
CTRL-a d

If you want to use more advanced functions then refer to wiki

ravisingh1 · 09-07-2013, 11:03 AM

Thank you both grabie2 and 273 very much.
@273, the way you described made me completely clear. Great!

Just one thing:
As wiki quotes

Quote:

GNU Screen can be thought of as a text version of graphical window managers, or as a way of putting virtual terminals into any login session.

I connect to remote server via ssh. Now I enter commands in a terminal. Is wiki referring this terminal as virtual.

Also, I had asked something similar to this point in my 1st post in this thread (as below)

Quote:

Originally Posted by ravisingh1

Just a general question: Once disconnected , is it possible to go back (after reconnection) to the previous terminal where I left. If no, then how w'd a user proceed ahead if the remote terminal (is it remote terminal or local?) awaits for user's input and the user got disconnected.

This was my doubt that when I login to remote server, the terminal which I see that i didn't open intentionally, is the wiki referring this as virtual. Or, that terminal is a real terminal of the server and when I ssh the remote, I get connected to the terminal.

dt64 · 09-08-2013, 05:36 AM

Quote:

Originally Posted by ravisingh1

I connect to remote server via ssh. Now I enter commands in a terminal. Is wiki referring this terminal as virtual.

This was my doubt that when I login to remote server, the terminal which I see that i didn't open intentionally, is the wiki referring this as virtual. Or, that terminal is a real terminal of the server and when I ssh the remote, I get connected to the terminal.

Not exactly. The command line interface on the remote computer you are working on is the terminal, where the terminal is local but all inouts are being send to the remote machine and all output from the remote machine is presented on your local machine terminal.
In case your local machine runs Windows you maybe use putty to connect to the remote machine, so the putty programm is your terminal connected to the remote server. In Linux it's the same, you connect your local terminal to the remote machine.
That's why for Unix-like systems it doesn't really matter if you work locally or remote, it all appears to be the same. Even when you work on the local machine the terminal connects to the local host by network-like functions.

Now the virtual terminals in screen are like multiple desktops in your window manager, e.g. Gnome. There you can have a workspace with programs running and if you want to have a new empty desktop but leave your work in the state it is, you just switch to the next workspace, do your stuff and you can always switch back to the other.
In local text terminals you can usually do the same using <alt>+<F1..F6> depending on your setup. With screen you can do this within the same terminal, so you can have multiple foreground programms running and switch between them as you like.