There does actually seem to be a delay.  For some reason, just typing something on the command prompt causes this delay.

shell did not close, sending SIGHUP

The problem is shell does not exit with something typed in, so Konsole starts sending signals to exit the shell and wait for the result.
EOF -> 1s
SIGHUP -> 1s
SIGKILL -> no wait

As I'm compilling, running and testing codes, usually EOF and SIGHUP does the job, I never got to the stage of SIGKILL.

Interesting enough, I get this now always with using Konsole on FreeBSD with zsh:

Open Konsole, then just quit it:

shell did not close, sending SIGHUP
Process  87805  did not die with SIGHUP

I debugged a bit, _shellProcess->sendEof() in closeInNormalWay() is able to send the EOF char, but the shell process really terminates "never" after that, if one swaps the _shellProcess->waitForFinished(1000) with _shellProcess->waitForFinished(-1) we just hang infinitely.

On the other side, this seems to work properly on e.g. Linux.

Interesting enough, manual sending of SIGHUP instantly terminates the session.
(if one doesn't try to close the window first)

If I remove the code path for the in closeInNormalWay()

 _shellProcess->sendEof();

all works nicely (e.g. SIGHUP works), too.

After 

 _shellProcess->sendEof();

manually sending SIGHUP doesn't work at all, too.

I looked a bit more how other terminal emulators work here.

At least for me, xterm, gnome terminal and the "Konsole" fork qterminal just do the sighup/close variant.

I assume the sendEof was integrated for bug 185140 (and then later one added the workaround to do that only for some known shells to avoid issues with other applications like tmux).

Might it be a good idea to reconsider this change, given other terminal emulators didn't follow suite?

CCing some BSD person:

Adriaan, with current KDE ports, can you confirm, too, that closing konsole window stalls and produces 

shell did not close, sending SIGHUP
Process  87805  did not die with SIGHUP

on the terminal it was launched from?

For me this let's Kate stall on close per internal open terminal 2 seconds.

that sendEOF stuff is all nonsense; it's already explained in bug #185140 why it's technically unnecessary.

bash isn't the only process that will behave weirdly on EOF when a line has been started - just try an interactive 'cat'.

also, this can't possibly work reliably, as only the foreground process will get the EOF. SIGHUP was introduced for a reason, after all.

so as far as i'm concerned, that EOF stuff should be just reverted (including the workarounds that followed it).

Would be the preferred solution for me, too, and directly solve that it doesn't work on BSD in all cases I tried it.

I can prepare some merge request for that.

BSD hat:

- frameworks 5.83.0
- konsole-21.04.3

Scenario:

- start xterm (in whatever way is appropriate)
- launch konsole from there
- type "derp" in konsole (no enter)
- Ctrl-Shift-W (there is no File > Close Tab in my Konsole version)
- Output as described

Here's what I see in xterm:

```
[adridg@beastie ~]$ konsole
kf.windowsystem: Loaded plugin "/usr/local/lib/qt5/plugins/kf5/kwindowsystem/KF5WindowSystemX11Plugin.so" for platform "xcb"
shell did not close, sending SIGHUP
Process  258  did not die with SIGHUP
[adridg@beastie ~]$ 
```

@Oswald: thanks for the fast reply.

@Adriaan: see also bug 185140, from comment#9, very relevant.

FWIW, I tested the scenario Ahmed describes in the linked bug, on FreeBSD:

- start xterm
- start konsole from xterm
- in konsole, type "kwrite &" (enter), wait for kwrite to come up, then:
  - close konsole with ^D (terminating the shell in konsole); kwrite stays running
  - close konsole with Ctrl-Shift-W (terminating konsole); error messages about shell not closing, followed by kwrite dying (after a short delay)

- start xterm
- start another xterm from xterm
- in xterm, type "kwrite &" (enter), wait for kwrite to come up, then:
  - close xterm with ^D (terminating the shell in xterm); write stays running
  - close xterm with the close-window button (the red X, upper-right in the kwin decoration); kwrite is killed quickly

So the two are consistent (and frankly, the inconsistency of what-happens-to-gui-applications-launched-from-the-shell depending on how the terminal emulator is closed, would cause me to file a bug report claiming that backgrounded processes should be left alone).

(In reply to groot from comment #12)
>  - close konsole with Ctrl-Shift-W (terminating konsole); error messages about shell not closing, followed by kwrite dying (after a short delay)

Actually on Linux the background process doesn't die at all in either case, so that is inconsistent with other terminal emulators (Konsole is sending an EOF when the user didn't actually send an EOF, the user closed the window).

[...]
> So the two are consistent (and frankly, the inconsistency of what-happens-to-gui-applications-launched-from-the-shell depending on how the terminal emulator is closed, would cause me to file a bug report claiming that backgrounded processes should be left alone).

I think you'd have to file that bug report with the shell you're using, because it's different in e.g. zsh than bash....

IMHO, the user closing the window isn't the same as the user sending EOF to the shell.

(In reply to Ahmad Samir from comment #13)
> (In reply to groot from comment #12)
> >  - close konsole with Ctrl-Shift-W (terminating konsole); error messages about shell not closing, followed by kwrite dying (after a short delay)
> 
> Actually on Linux the background process doesn't die at all in either case,
> so that is inconsistent with other terminal emulators (Konsole is sending an
> EOF when the user didn't actually send an EOF, the user closed the window).
> 
> [...]
> > So the two are consistent (and frankly, the inconsistency of what-happens-to-gui-applications-launched-from-the-shell depending on how the terminal emulator is closed, would cause me to file a bug report claiming that backgrounded processes should be left alone).
> 
> I think you'd have to file that bug report with the shell you're using,
> because it's different in e.g. zsh than bash....
> 
> IMHO, the user closing the window isn't the same as the user sending EOF to
> the shell.

Yes, and e.g. try "exit" in zsh, that will terminate kwrite & processes, too.

I think the current behavior is just not ok.
It is inconsistent with what other terminals do (e.g. xterm, gnome-terminal (and all other vte based terminals), qterminal and even the terminal in e.g. vs code)

Beside this, as the code shows, we already have "workarounds" to avoid misbehavior for applications and we have this bug for stuff that has half-typed lines (and in general it doesn't work on BSD)

I will create a merge request to alter this back to the old behavior.

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.

Perhaps somebody else has a better idea, but given at least all terminal emulators I tried behave like we did before the change for bug 185140 I think that is just the right way to handle session close.

In real-life, this issue results btw. in a lot more than just a few lines of warnings printed to the log/terminal.

I use Kate with x projects open, that means I will on FreeBSD have x * 2 * 2 seconds lag on exiting Kate (which looks more or less like it does hang).

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 185140

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 185140
(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