Terminal - running process is paused and not restored

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

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

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

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...

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.

> 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.

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']"

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)