QUIT signal handler ignored

[sdaschner]

Registering a handler for QUIT is ignored in my example applications. The other handlers (INT for Ctrl+c, TSTP, etc.) work as expected.

Example:

        try (Terminal terminal = TerminalBuilder.terminal()) {
            terminal.enterRawMode();

            terminal.handle(Terminal.Signal.INT, signal -> handleIntSignal());
            terminal.handle(Terminal.Signal.QUIT, signal -> {
                System.out.println("QUIT");
            });
            terminal.handle(Terminal.Signal.TSTP, signal -> {
                System.out.println("TSTP");
            });
            
            // ... input is read via terminal.reader().read(long) FWIW

When running the app, Ctrl+c and Ctrl+z result in the expected behavior (e.g. printing TSTP), but hitting Ctrl+\ prints a thread dump instead of QUIT.

This might be connected to #441.

I'm using Jline 3.23.0 and OpenJDK Runtime Environment Temurin-21.0.1+12 (build 21.0.1+12-LTS)

[gnodet]

Can you try with TerminalBuilder.builder().nativeSignals(true).build() when building the terminal ?

[sdaschner]

I've just tried, but no change and same outcome for the Ctrl+\ / QUIT signal... The TSTP signal is still handled as expected / as before.

[gnodet]

Could you provide a small reproducer maybe ? Is that specific to given a platform / environment ?

[sdaschner]

Sure, added here:

# checkout branch 912-quit-signal-handler
mvn clean package
java -jar target/quarkus-app/quarkus-run.jar
# press Ctrl+Z, prints TSTP
# press Ctrl+\, prints thread dump (instead of QUIT)
# press Ctrl+C, exists

Not sure if that's specific to an environment.. I'm using Linux with the Java/JLine versions mentioned above.

[gnodet]

It seems the only way to disable thread dump is to use -Xrs JVM option, but this means providing a replacement to catch signals from native code and dispatch those. This is not supported atm.

[sdaschner]

Hmm ok, thanks.

I'm just curious how the Signal.QUIT handler got in in the first place? Wasn't this tested in some Java runtime or does it depend on the JVM being used...?

[gnodet]

Hmm ok, thanks.

I'm just curious how the Signal.QUIT handler got in in the first place? Wasn't this tested in some Java runtime or does it depend on the JVM being used...?

I was wondering the exact same thing when I looked at it yesterday... I don't recall...

[gnodet]

Ah, I think I know. It does work if the client is not a JVM. For example, you can connect to a JLine based virtual terminal using an openssh client. In such case, the correct signal will be sent through the terminal and be caught and handled by the terminal.

[sdaschner]

Got it, thanks