Bug 185140

...then gnome-terminal is broken. Allowing jobs to run after the parent dies is creating orphans. (Whether gnome-terminal fails to shut down the shell in this case, or has a misfeature to detect still-running jobs and disown them, neither is a good idea.) To understand why this is bad, consider if the child process is a CLI program that needs an associated tty; you now have a child running that is useless but can't be stopped except by searching the system process list for it and using 'kill'. Neither the shell nor the terminal emulator should be second-guessing the user this way.

Fortunately, there are already ways to indicate that you wish a child process to ignore termination of the parent. The canonical way is 'nohup'. In bash, it's often easier to 'disown' such children (especially if you forgot to use 'nohup' to start the child), i.e. 'kate & disown'.

(Having said that, it would be nice if konsole would integrate detachable sessions, mainly so that crashes wouldn't take out all my shell sessions, but that's a different issue.)

@Robert: I'm closing this WONTFIX. Obviously as the maintainer you can decide that's wrong :-), but IMO "fixing" the "bug" exactly as written would be broken.

No, I agree with the reporter about what I expect to happen - and it does for me.  If I start a Konsole session, run kate& and quit the session and also Konsole then Kate stays running as I expect.

Also, about accidentally exiting with running jobs - the shell will, depending on its current settings, warn you about that.

I was able to reproduce.  Normally I close tabs by pressing Ctrl+D to tell the shell to exit - in this case, kate stays running in the 'background'.  If on the other hang I put kate in the background and close Konsole via File -> Close Window then Kate exits.

Right, I had no trouble reproducing, but I don't see how you can fix it other than to either a: not sighup bash, or b: rely on detecting bash complaining about stopped jobs, or...

Eew. I tried your way; apparently on EOF, bash happily disowns anything in the background without warning? That feels icky.

Ah, well, I guess the solution then is that Konsole should always try to kill shells with EOF before resorting to SIGHUP. I'm still not sure how I feel about that, though; what if I am running a process where EOF will cause something to happen that I don't want, but SIGHUP would be fine?

(Meanwhile, I have asked Chet if this is desired behavior. Alas, I would have to install another shell to check if this is typical.)

Hmm... well, I still don't really like this behavior, but Chet has spoken: http://permalink.gmane.org/gmane.comp.shells.bash.bugs/12602.

So according to him, Konsole should send EOF when anything (tab or whole app) is closed "nicely".

*** Bug 197875 has been marked as a duplicate of this bug. ***

(In reply to comment #6)

The unfortunate fact is currently most emulators do not. From my observation, xterm/vte/uxvt-unicode/mlterm all send SIGHUP thus killing background processes, while putty is the only one which sends EOF.

What's the situation on this bug? I returned to KDE after a long, long pause (and I'm very happy with it I have to say) but yesterday I lost several paragraphs on my text editor because I started it from konsole and it quitted without confirm when I close konsole by click instead of ctrl-D.

Long story short: I confirm the bug it's still there, 2014, version 2.12.1

Git commit 2f1c8cf397be6c91fcd60234740d9727650c1a87 by Martin T. H. Sandsmark.
Committed on 11/07/2016 at 10:57.
Pushed by sandsmark into branch 'master'.

Send EOF when closing first, before SIGHUP

According to the bash maintainer sending EOF is the appropriate way of
telling e. g. bash to quit:
    http://permalink.gmane.org/gmane.comp.shells.bash.bugs/12602

I wasn't able to get KPtyProcess to send that in a nice way (calling
setStandardInputFile(QProcess::nullDevice(), for example), so we fetch
the EOF character manually with tcgetattr and send that.
REVIEW: 128416

M  +16   -0    src/Pty.cpp
M  +5    -0    src/Pty.h
M  +9    -0    src/Session.cpp

http://commits.kde.org/konsole/2f1c8cf397be6c91fcd60234740d9727650c1a87

This completely breaks tmux (or screen). 
The currently active window gets the EOF is therefore closed whenever I close Konsole.
When I re-attach to the tmux session the window is of course gone.
This is unacceptable.

for posterity: this change was fundamentally misguided (as per matthew's first comment). as always when deviating from decades of established protocol, this broke several things, like the already mentioned tmux (which was worked around later) and bug #401898.

The gmane link seems to be broken; digging around in the bash bugs mailing list archives, I think this is the thread linked in comment#6:
https://lists.gnu.org/archive/html/bug-bash/2009-03/msg00089.html

This is a complicated issue... so I started by testing this a bit:
- first case:
kwrite &
Ctrl+D

- second case:
kwrite &
closing window using the close button on the titlebar


With konsole, kwrite stays running in both cases.

With xterm, gnome-terminal or terminology:
- kwrite stays running
- kwrite is killed

so konsole is the odd one out.

So far it looks like:
- it would be better to not send EOF manually, if the user sends an EOF when closing, then that's a the "nice" way of closing a shell (bash specifically, since that's what the links in this report were talking about) and a background process would stay running
- otherwise we send SIGHUP, and a background process (if any) is killed

The user can always use `foo & disown`, if the requirement is to always leave a background process running, regardless of how the terminal emulator window is closed.

A possibly relevant merge request was started @ https://invent.kde.org/utilities/konsole/-/merge_requests/449

Merge request to revert the ancient change (and the later done workarounds to avoid other issues like closing tmux) added.

Git commit 3d967a597472a75b2afbd75afb20d7f44a3881f2 by Ahmad Samir, on behalf of Christoph Cullmann.
Committed on 13/08/2021 at 12:57.
Pushed by ahmadsamir into branch 'master'.

improve session closing behavior

the new session close behavior is again the old

- first send SIGHUP and wait one second if that works
- then hard kill

before we tried to send an EOF character
this needed workaround to not kill "non shell" programs
unexpected and doesn't work e.g. if

- you have some not finished command input in your shell
- on e.g. FreeBSD in general

When closing the session with some background process still running:
- using Ctrl+D (which sends EOF) will leave that background process running
  (which is the expected behaviour with e.g. BASH:
  https://lists.gnu.org/archive/html/bug-bash/2009-03/msg00091.html)
- using e.g. the close button on the titlebar will close the session and kill any background processes

You can also use 'somecommand & disown', if you want to ensure background processes
aren't killed when you close a konsole window.
Related: bug 401898

M  +0    -16   src/Pty.cpp
M  +0    -5    src/Pty.h
M  +7    -18   src/session/Session.cpp

https://invent.kde.org/utilities/konsole/commit/3d967a597472a75b2afbd75afb20d7f44a3881f2

Git commit 18dc0fde2b47b70ac65e4a0400ed0b79c12b1196 by Kurt Hindenburg, on behalf of Christoph Cullmann.
Committed on 06/09/2021 at 16:35.
Pushed by hindenburg into branch 'release/21.08'.

improve session closing behavior

the new session close behavior is again the old

- first send SIGHUP and wait one second if that works
- then hard kill

before we tried to send an EOF character
this needed workaround to not kill "non shell" programs
unexpected and doesn't work e.g. if

- you have some not finished command input in your shell
- on e.g. FreeBSD in general

When closing the session with some background process still running:
- using Ctrl+D (which sends EOF) will leave that background process running
  (which is the expected behaviour with e.g. BASH:
  https://lists.gnu.org/archive/html/bug-bash/2009-03/msg00091.html)
- using e.g. the close button on the titlebar will close the session and kill any background processes

You can also use 'somecommand & disown', if you want to ensure background processes
aren't killed when you close a konsole window.
Related: bug 401898
(cherry picked from commit 3d967a597472a75b2afbd75afb20d7f44a3881f2)

M  +0    -16   src/Pty.cpp
M  +0    -5    src/Pty.h
M  +7    -18   src/session/Session.cpp

https://invent.kde.org/utilities/konsole/commit/18dc0fde2b47b70ac65e4a0400ed0b79c12b1196