SSH Sessions - How do they work in terms of applications?
 

I've been using SSH for a long time to remotely access my machine, but I don't understand how SSH sessions work in terms of the programs that run under these sessions.

For example, I don't understand why the programs I launch under an SSH session are terminated if I terminate the session. Why don't they continue to run? The ultimate session runs on the local machine, correct? So, each time I create a new SSH session, why are my startup programs relaunched? Wouldn't that create multiple instances of several programs? I run a webserver on my Ubuntu machine, and it doesn't seem to be affected by sessions. If I terminate the session it is still running, but my wine program does not continue to run. Why is that?

Right now, I've set up my Ubuntu machine to run a wine program called Autokick as a Startup application. When I start a session, it loads and runs. However, if I close that session, it no longer runs. By adding a program to the startup applications, it loads when the actual local computer boots, correct? Thus, if I were to have Autokick run from the session that is created once the local machine loads Ubuntu, would Autokick continue to run even when I create new sessions over SSH?

I'm so confused. Please help me understand this better. I just don't know how apache can run all the time despite sessions, but a wine program cannot.

Is there no way to use SSH to login to the current session running on the local machine? I don't want to keep creating sessions, if it launches programs every time a session is created.

I use NoMachine on Ubuntu 10.04
own3mall is online now Report Post Edit/Delete Message

There are a couple of concepts at play here. Most importantly is the concpet of a 'controlling terminal'. When you launch an application, it has a standard input, which is normally connected to the console/terminal supporting your login. The application cannot receive input without this terminal, so it quits if the terminal disconnects. The mechanism is that the kernel sends the process a SIGHUP (hangup; like when a modem drops its phone connection) signal. Unhandled, the default behavior on receipt of SIGHUP is to terminate.

A 'daemon' process is a process that does not require or have a controlling terminal, and so is happy to run without one. This is required for most system services, since a controlling terminal can only exist as a product of a login, and system services run without any login occurring. The web server that you note is just such a service. Many others can usually be found in /etc/init.d.

You can use a couple of different tricks to keep your processes alive after a login session terminates. You can run it under nohup (man nohup for details) to keep the process running after the terminal dies. You can run the application in a Gnu screen session. This is probably the most useful, as it allows you to interact with the process, and also to re-connect later from other sessions, even concurrently by multiple users, if so configured.

There are various states/events that trigger files to be read or processes invoked. Boot-time is one; login-time is another; creation of a new shell process is yet another common case where config files are read. Applications that launch at boot-time are called services, and there are a small number of standard systems used by the various Linux distros that determine what services get launched and killed, in what order, etc. When you login (as with SSH), your shell will read a prescribed list of configuration files (man bash for details), and when you create a new shell without logging in (like launching an xterm from your desktop), a subset of those config files will be read.

If you need to set up applications to be automatically launched, you can modify the existing scripts to do so. It is up to you to determine at what level your processes need to be launched. Wine applications will be especially troublesome, since they probably also require an X server, and that is not going to exist at all at boot time, and cannot be suspended with tools like screen.

--- rod.

Thanks for the helpful information theNbomr. It's making more sense to me now.

Is there a way I can configure the program to run as a daemon? nohup doesn't seem to work. Or better yet, is there a way I can make the application launch only after the computer boots up Ubuntu which logs into my account and not have it launch during created sessions?

You can add applications to launch in /etc/rc.local. It is a shell script that executes after all of the init.d services are launched as part of the boot process. Is your application one that requires you to interact with it via a console? If so, then using screen to support it is probably your best bet, but that is tricky to so at boot time.
Please note that boot-time and login time are distinctly different phases of operation in Linux. It is quite possible to have a Linux host perform useful work without anyone ever logging in to it. File and network servers are types of hosts that commonly operate in this way.

I don't know of any way to make a program into a daemon without modifying the application itself. You would have to have the source code, and an understanding of the Linux process model, and some understanding of the internal workings of the program to effect such a change.

What about nohup 'doesn't seem to work'?
--- rod.