Environment
- OS: RHEL 9 (x86_64), home directory on NFS
- Eclipse Version: 4.38, Java 25
- Plugin Version: 0.20.0.202607100822 (copilot-language-server 1.509.5)
Describe the bug
copilot-language-server never gets killed when Eclipse exits uncleanly. The processes
get re-parented to PID 1 and just stay there. I found 11 of them on one machine, the
oldest 8 days old, roughly 1.2 GB RSS in total. After I killed those, 3 more had piled
up within two hours of normal use.
They all look like this:
pid=<A> ppid=1 age=693280s
<eclipse-configuration>/org.eclipse.osgi/<id>/0/.cp/copilot-agent/copilot-language-server --stdio
I think the reason is lastDocumentDisconnectedTimeout="2147483647" in
com.microsoft.copilot.eclipse.core/plugin.xml. It used to be 30 and was changed to
Integer.MAX_VALUE in 2c6b545 ("fix - Defer shutdown time to MAX integer"), with a TODO
on the same line. So LSP4E never stops the server on idle, and the only thing that can
stop it is a clean bundle stop at shutdown.
In my case shutdown was never clean, because Copilot's own activation job was stuck:
Job found still running after platform shutdown. Jobs should be canceled by the
plugin that scheduled them during shutdown:
com.microsoft.copilot.eclipse.ui.CopilotUi$1 RUNNING
com.microsoft.copilot.eclipse.ui.preferences.McpPreferencePage$1 RUNNING
so every exit leaked one more server. singleton="true" doesn't help, since the old ones
aren't children of any running IDE anymore.
To Reproduce
- Start Eclipse with the plugin and let Copilot activate.
- Get the platform into a state where it can't shut down cleanly. In my case the
activation job was blocked; killing the JVM has the same effect.
pgrep -af copilot-language-server — the server is still running with ppid 1.- Repeat. They accumulate.
Expected behavior
The language server should be terminated when its IDE goes away, including on a hard
exit.
Additional context
This isn't only about wasted memory. The orphans keep holding locks on shared state
under $XDG_CONFIG_HOME/github-copilot. In our case they starved the SQLite checkpoint
on auth.db until the plugin stopped working altogether — filing that separately.
It's also self-reinforcing: a stuck activation job prevents a clean shutdown, which
leaks another server, which makes contention worse the next time around.
Would it be possible to destroy the process from a JVM shutdown hook too, so it doesn't
depend on the OSGi stop path? Reaping servers whose parent IDE no longer exists at
startup would also clean up the ones already out there.
Environment
Describe the bug
copilot-language-server never gets killed when Eclipse exits uncleanly. The processes
get re-parented to PID 1 and just stay there. I found 11 of them on one machine, the
oldest 8 days old, roughly 1.2 GB RSS in total. After I killed those, 3 more had piled
up within two hours of normal use.
They all look like this:
I think the reason is
lastDocumentDisconnectedTimeout="2147483647"incom.microsoft.copilot.eclipse.core/plugin.xml. It used to be 30 and was changed to
Integer.MAX_VALUE in 2c6b545 ("fix - Defer shutdown time to MAX integer"), with a TODO
on the same line. So LSP4E never stops the server on idle, and the only thing that can
stop it is a clean bundle stop at shutdown.
In my case shutdown was never clean, because Copilot's own activation job was stuck:
so every exit leaked one more server. singleton="true" doesn't help, since the old ones
aren't children of any running IDE anymore.
To Reproduce
activation job was blocked; killing the JVM has the same effect.
pgrep -af copilot-language-server— the server is still running with ppid 1.Expected behavior
The language server should be terminated when its IDE goes away, including on a hard
exit.
Additional context
This isn't only about wasted memory. The orphans keep holding locks on shared state
under $XDG_CONFIG_HOME/github-copilot. In our case they starved the SQLite checkpoint
on auth.db until the plugin stopped working altogether — filing that separately.
It's also self-reinforcing: a stuck activation job prevents a clean shutdown, which
leaks another server, which makes contention worse the next time around.
Would it be possible to destroy the process from a JVM shutdown hook too, so it doesn't
depend on the OSGi stop path? Reaping servers whose parent IDE no longer exists at
startup would also clean up the ones already out there.