PostgreSQL processes remain running after JabRef crashes or is forcefully terminated

[ungerts]

JabRef version

Latest development branch build (please note build date below)

Operating system

Windows

Details on version and operating system

Windows 10

Checked with the latest development build (copy version output from About dialog)

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

When JabRef crashes or is forcefully terminated (e.g., via kill -9 or Task Manager), associated PostgreSQL processes often remain running. These orphaned processes continue to consume system resources unnecessarily.

Steps to Reproduce

1. Start JabRef with a PostgreSQL backend.
2. Forcefully terminate JabRef (e.g., using kill -9 or Task Manager).
3. Open Task Manager (Windows) or use ps on Linux/macOS.
4. Observe that multiple PostgreSQL Server processes are still running.

Expected Behavior

All PostgreSQL-related processes spawned by JabRef should terminate when JabRef is unexpectedly closed.

Actual Behavior

PostgreSQL processes persist after JabRef exits unexpectedly, leading to orphaned background processes.

Appendix

Screenshot

Screenshot shows several idle PostgreSQL Server processes still running after JabRef was terminated.

[Siedlerchr]

Sigkill cannot be caught, but it would probably make sense to add a shutdown hook to ensure running instances are closed when sigterm occurs

[subhramit]

I have faced this too (noticed this yesterday). Every time I close and re-run JabRef (when running via IntelliJ), my task manager shows the old Postgres instance running. On running a new JabRef session again, a new Postgres session is also launched. After 5-6 trials, I was wondering why my system was lagging so much, then checked the task manager which had 6 running postgres instances.

Edit - what I meant was another implication of this is lag during development.

Edit - more details:
1st run: 1 background process, 6 instances:

Second run using IntelliJ reload:

Now there are 2 background processes, 12 instances:

All of them on CPU 00:

And so on...

[Siedlerchr]

https://adambien.blog/roller/abien/entry/sigterm_sigint_sigkill_and_java
something like this would probably help

https://docs.oracle.com/en/java/javase/21/troubleshoot/handle-signals-and-exceptions.html

[subhramit]

Tried with:

public class Launcher {

    public static void main(String[] args) {
       ...

        PostgreServer postgreServer = new PostgreServer();
        Injector.setModelOrService(PostgreServer.class, postgreServer);
        
        Runtime.getRuntime().addShutdownHook(new Thread(() -> {
            if (postgreServer != null) {
                try {
                    postgreServer.shutdown();
                    System.out.println("PostgreServer successfully shut down");
                } catch (Exception e) {
                    System.err.println("Error shutting down PostgreServer: " + e.getMessage());
                }
            }
        }));

        JabRefGUI.setup(uiCommands, preferences, fileUpdateMonitor);
        JabRefGUI.launch(JabRefGUI.class, args);
    }
}

Didn't work

[subhramit]

Tried with:
...
Didn't work

On checking logs, neither the try nor the catch is executed. On reading more, it appears that it's because there is no way to reliably execute code in case of a SIGKILL (the shutdownhook helps in case of SIGTERM and SIGINT).

[Siedlerchr]

Sigkill is not catchable. That would be against its purpose Subhramit Basu ***@***.***> schrieb am Fr., 28. März 2025, 19:42:

…

Tried with: ... Didn't work On checking logs, neither the try nor the catch is executed. On reading more, it appears that it's because there is no way to reliably execute code in case of a SIGKILL (the shutdownhook helps in case of SIGTERM and SIGINT). — Reply to this email directly, view it on GitHub <#12844 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOFZESHHWCNLJHJILYGWL2WWJ2ZAVCNFSM6AAAAABZ7S5722VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRSGE2TMMRXGY> . You are receiving this because you commented.Message ID: ***@***.***> [image: subhramit]*subhramit* left a comment (JabRef/jabref#12844) <#12844 (comment)> Tried with: ... Didn't work On checking logs, neither the try nor the catch is executed. On reading more, it appears that it's because there is no way to reliably execute code in case of a SIGKILL (the shutdownhook helps in case of SIGTERM and SIGINT). — Reply to this email directly, view it on GitHub <#12844 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACOFZESHHWCNLJHJILYGWL2WWJ2ZAVCNFSM6AAAAABZ7S5722VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDONRSGE2TMMRXGY> . You are receiving this because you commented.Message ID: ***@***.***>

[subhramit]

Hmm...so is this issue unsolvable from the perspective of shutdown it seems..

[koppor]

Hmm...so is this issue unsolvable from the perspective of shutdown it seems..

Idea for workaround: On start of new JabRef instance, old postgres (from JabRef) could be re-used (or killed)

[ungerts]

Idea for workaround: On start of new JabRef instance, old postgres (from JabRef) could be re-used (or killed)

To me, this feels a bit like performing "magic" on the user's machine. Implementing such behavior is likely to be complex and error-prone.

• PostgreSQL ports are allocated automatically. As a result, the application would need to either:

  • Detect the port currently in use at runtime, or
  • Persist the assigned port on first launch and reuse it upon restart.

• Multiple PostgreSQL instances might be running on the user's system:

  • Some could be installed manually by the user.
  • Others might be leftover (or orphaned) instances from previous JabRef sessions.

This leads to a critical question: Which instance should JabRef attempt to reuse - or safely shut down?