Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

[Bug] copilot-language-server processes are left behind when Eclipse exits

オープン
  • 何か問題がありますか？
#440 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 3 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
バグ
明瞭さ
おおむね明確
活発さ
活発
技術スタック
java
領域
desktop

調査の方向性

com.microsoft.copilot.eclipse.core/plugin.xml と、LSP4E を通じて管理される copilot-language-server のライフサイクルから調査を始めます。lastDocumentDisconnectedTimeout の設定と OSGi のシャットダウン経路を確認します。com.microsoft.copilot.eclipse.ui.CopilotUi$1 と報告されているアクティベーション・ジョブを追跡し、その後、JVM が強制終了した場合にクリーンアップがどのように動作するかを確認します。Eclipse の終了後に孤立した copilot-language-server プロセスや共有状態のロックが残らなければ完了です。

索引モデルが issue の本文から書いたものです。

説明

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 2c6b5452 ("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

  1. Start Eclipse with the plugin and let Copilot activate.
  2. 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.
  3. pgrep -af copilot-language-server — the server is still running with ppid 1.
  4. 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.

主要言語
Java
スター
128
フォーク
66
平均マージ
2日 3時間
マージ済み PR（30日）
6

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

microsoft/copilot-for-eclipse のほかの issue

microsoft/copilot-for-eclipse の issue をすべて見る

似ている issue

Java の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。