Terminal - running process is paused and not restored

[Sturm Flut]

When the terminal goes out of focus with a long running process, the process is paused and not restored when the terminal comes back into focus.

There are 2 different camps of thought on how to solve this.

***
The first is to allow these processes to run in the background:
A simple solution would be to give a lifecycle exception to the terminal app.

Another solution would be to use a special command that would run a command in the background. In the same manner that the sudo command runs any command as a different user, another command (e.g. runbg) could run any command as an external background running program.
  This command might do something along the lines of forking the process so that it is not owned by the terminal app and thus not dependent on the terminal to keep running.
  This solution giving the user more control without compromising the experience when background processing is not needed.

***
The second solution is to automatically do the equivalent of running the 'fg' command when the terminal is back in focus. This allows many long running processes to keep working seamlessly while not compromising the battery and lifecycle design of the OS. In my experience, I was able to 'fg' an ssh command after around 40 mins of the process being paused, and continue with my SSH session unhindered.

[Evan McIntire (mcintire-evan)]

https://bugs.launchpad.net/ubuntu-terminal-app/+bug/1397119 is related to this issue

[Selene ToyKeeper (toykeeper)]

It would be nice if one could just "nohup mycommand" or similar to keep a process from getting suspended on a per-command basis.

[Sam Bull (dreamsorcerer)]

As bug #1397119 keeps getting marked as a duplicate, I've updated this bug description to more accurately reflect the ideas of both.

[AlainKnaff (kubuntu-misc)]

A couple of remarks:
- it's not just "long running processes" that are affected, but even interactive ones, such as editors. Actually interactive processes tend to get roughed up more than heavy calculations, as usually fg will not restore their terminal settings (noecho, raw, ...) correctly. Use case: browsing a shopping list in v.i. while in the shop, occasionally putting the phone into the pocket (and locking it) in order to have a free hand to pick up items.
- actually there already *is* a "special command that would run a command in the background" (... or rather that would _prevent_ it from being automatically backgrounded), namely exec ssh localhost but you have to actually think about using it before absent-mindedly locking your phone and putting it into your pocket...

[Sam Bull (dreamsorcerer)]

By long running processes, I mean processes which haven't completed within a few seconds of being started (as opposed to CPU intensive processes). Interactive programs by their very nature, are obviously long running processes.

The exec command does solve the issue of restoring the process to the foreground cleanly, but requires replacing the terminal process itself (so when the process exits the terminal app also exits).
It also does not actually allow the process to continue running, it is still paused under the normal lifecycle rules.
Therefore does not (on it own) solve the issue properly.

[AlainKnaff (kubuntu-misc)]

> but requires replacing the terminal process itself (so when the process exits the terminal app also exits)

True enough. Which might become annoying if you mistype... so what I did, I set up an alias by putting the following into my ~/.bash_aliases :

alias m="exec ssh localhost"

Just typing "m" on its own then gives me a "protected" session.

... or, if you really wanted to fully automate this, you could put the following into your ~/.bashrc:

if [ -z "$SSH_TTY" ] ; then
        exec ssh localhost
fi

... so that each session which is not already an ssh session gets nicely wrapped. But in the end I decided that it was a tad too risky, if ever for some reason sshd stopped setting $SSH_TTY I would effectively have locked me out of my phone...

> It also does not actually allow the process to continue running, it is still paused under the normal lifecycle rules.

The ssh client itself is indeed paused (ps from another session shows it in state T), but any processes running "under" it are left untouched (because they are not actually children of the ssh client, but children of the server which doesn't even notice what happened to its client). And when getting back to the terminal, the ssh client is woken up cleanly, and you can continue to use the session as if nothing had happened. What is all I'd need, really.

> Therefore does not (on it own) solve the issue properly.

Well, at least it makes the issue much less annoying. It doesn't kick me out of vi with a messed up terminal any longer... :-)

Of course, it would still be preferable if the issue was properly fixed in the terminal app, but at least now we have a workaround until a proper fix is ready.

[lgd (lgd)]

Am 29.04.2016 um 15:50 schrieb AlainKnaff:
> Of course, it would still be preferable if the issue was properly fixed
> in the terminal app, but at least now we have a workaround until a
> proper fix is ready.

You can expand your output of
gsettings get com.canonical.qtmir lifecycle-exempt-appids
with the terminal-app by adding it to the output (in ONE line):

gsettings set com.canonical.qtmir lifecycle-exempt-appids
"['com.ubuntu.music', 'com.ubuntu.terminal']"

[AlainKnaff (kubuntu-misc)]

Interesting. This does indeed work. Thanks for the tip.

Interesting buglet: when executing gsettings in an ssh session, it segfaults (but it does works fine, with the intended effect, when executed in the terminal)