"Binary LSP agent start failed" sometimes

[iloveeclipse]

Feedback source

None

GitHub Copilot plugin version

0.14.0.202512112209

Eclipse IDE and version

4.38

Platform

RHEL 9.6, Java 25

uname -a
Linux socbn410 5.14.0-570.12.1.el9_6.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Apr 4 10:41:31 EDT 2025 x86_64 x86_64 x86_64 GNU/Linux

java -version
openjdk version "25" 2025-09-16 LTS
OpenJDK Runtime Environment Temurin-25+36 (build 25+36-LTS)
OpenJDK 64-Bit Server VM Temurin-25+36 (build 25+36-LTS, mixed mode, sharing)

Steps to reproduce

Unfortunately only seen in automated tests (~50 executions at night, maybe 1 would fail).

Logs (optional)

!ENTRY com.microsoft.copilot.eclipse 4 0 2026-01-27 02:26:27.908
!MESSAGE [Error] Binary LSP agent start failed. Retrying with JS agent.
!STACK 0
java.io.IOException: Cannot run program "/workspaces/socvn352/jenkinsbs/ws-integration-default_el9/opt/hp93000/soc/segments/eclipse/eclipseForTest/configuration/org.eclipse.osgi/289/0/.cp/copilot-agent/copilot-language-server": Exec failed, error: 26 (Text file busy) 
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1112)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1046)
	at org.eclipse.lsp4e.server.ProcessStreamConnectionProvider.start(ProcessStreamConnectionProvider.java:58)
	at com.microsoft.copilot.eclipse.core.lsp.LsStreamConnectionProvider.startBinaryLspAgent(LsStreamConnectionProvider.java:77)
	at com.microsoft.copilot.eclipse.core.lsp.LsStreamConnectionProvider.start(LsStreamConnectionProvider.java:60)
	at org.eclipse.lsp4e.LanguageServerWrapper.lambda$0(LanguageServerWrapper.java:429)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.run(CompletableFuture.java:1789)
	at java.base/java.util.concurrent.CompletableFuture$AsyncSupply.exec(CompletableFuture.java:1781)
	at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511)
	at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1450)
	at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2019)
	at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187)
Caused by: java.io.IOException: Exec failed, error: 26 (Text file busy) 
	at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
	at java.base/java.lang.ProcessImpl.<init>(ProcessImpl.java:300)
	at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:231)
	at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1078)
	... 11 more

Expected behavior

No errors

Actual behavior

LS can't start

Additional information

No response

[iloveeclipse]

OK, AI helped a bit to understand the root cause and also proposed some workarounds:

"Text file busy" Error (errno 26) in forkAndExec

This error occurs when Linux attempts to execute a file that is currently open for writing by another process. Specifically, error 26 (ETXTBSY) is returned by the kernel when you try to execve() a binary that hasn't been fully written or closed yet.

Common Causes on RHEL 9.6 / Java 25

	1. Race condition during extraction - The Copilot agent binary is being extracted to the configuration directory while simultaneously another process (or thread) attempts to execute it before the file handle is closed.
	2. Antivirus/Security scanning - Security software (e.g., SELinux, ClamAV, or enterprise endpoint protection) may hold the file open for scanning after extraction.
	3. NFS or network filesystem - If the Eclipse configuration directory is on a network mount, file locks may not release synchronously.
	4. Java 25 virtual threads - If using virtual threads, the concurrent extraction and execution could hit a timing window more frequently than older thread models.
	5. Copy-on-write filesystems - Btrfs or overlay filesystems (common in containers) can exhibit this race condition more frequently.

Workarounds

	•  Add a short delay before executing newly extracted binaries
	•  Sync and close file handles explicitly after extraction
	•  Move the configuration directory to a local (non-NFS) filesystem

Why It's Random

The timing between file write completion and execve() is non-deterministic, depending on system load, I/O scheduling, and thread scheduling—hence the intermittent nature.

[iloveeclipse]

So I guess "Add a short delay before executing newly extracted binaries" would be probably helpful...

PS: The tests run code on xfs (local) file system , so it is not an NFS issue.

[jdneo]

Is that because of the CLS are launched more frequently when running the tests?

[iloveeclipse]

We have ~20 test suites (or more) per one application test execution, each starts new Eclipse (and so CLS), so there are few startups. So there is lot of data.

[jdneo]

Is it possible to change the start up logic in the tests to avoid this?

[iloveeclipse]

To avoid what? CLS startup? Actually yes, because only ~10 tests test MCP related stuff where Copilot is involved, the rest of ~ 10.000+ tests doesn't need CLS at all, it is there because it is part of application.

So if there would be possibility to make sure that CLS is not started at all automatically at startup, but can be started on demand if needed, we could use it. I've seen the bundle uses early startup extension point - if that could be removed (and CLS is started if the code that needs is would be triggered) it would be a solution.

[jdneo]

I mean is this error caused by multiple tests are running parallel?

[iloveeclipse]

No, never. Tests have exclusive control over current VM instance & file system and run sequentially.

[jdneo]

Ok, so sounds like the binary is being executed too early before it is completely extracted to the config dir?

[iloveeclipse]

Yes, something like this.

[jdneo]

Thanks for the explanation. I do not have the test environment for validation. If the fix works well on your side, we can merge it.

[iloveeclipse]

If the fix works well on your side, we can merge it.

Well, since I can only randomly reproduce in automated tests, I need a "regular" (nightly) bundle build with the fix which I can use on CI. But I assume the proposed workaround should not harm anyone as it only kicks in if native LS startup is failed anyway. So would be good to have the patch soon in a nightly.