jenkins-cli.jar build command with -s flag aborts long-running builds after Jenkins LTS upgrade from 2.479.1 to 2.541.2

[rshmanuka24]

Jenkins and plugins versions report

After upgrading Jenkins LTS from 2.479.1 to 2.541.2, all builds triggered via jenkins-cli.jar using the -s flag (wait for completion) are being aborted mid-run after the build has been running for a period of time. Builds triggered without -s complete successfully, confirming the issue is specific to the CLI wait/monitor behavior.

The -f flag (stream console output) doesn't provide success or failure status. And due to our project restrictions websocket cli methods can't be used.

What Operating System are you using (both controller, and any agents involved in the problem)?

Controller:

• Linux (os.version=5.15.0-177-generic, amd64)
• Java 21

Agents:

• Linux (Java 21) & Docker
• Windows 11 (Java 21)

Reproduction steps

Upgrade Jenkins LTS from 2.479.1 to 2.541.2
Trigger a long-running build using the CLI with the -s flag:

java.exe -jar jenkins-cli.jar -s https://<JENKINS_URL>/ -http -auth : build <JOB_NAME> -s # Observe that the build starts successfully but is aborted after running for some time.

Expected Results

The CLI should hold the connection open until the build completes and return the final build result (SUCCESS / FAILURE) with the appropriate exit code.

Actual Results

The build is aborted mid-execution. The CLI disconnects an job aborted before the build finishes.

Started <JOB_NAME> #X
ERROR: null

Anything else?

No response

Are you interested in contributing a fix?

No response

[MarkEWaite]

I'm unable to duplicate the issue as reported.

Please provide enough details so that others can duplicate the issue from a fresh Jenkins installation. I've collected the files that I used to try to duplicate the issue as gh-26862.zip

Steps that I took while trying to duplicate the issue:

1. Download and run Jenkins 2.541.2 on a Linux computer using Java 21, set the number of executors on the controller to 0
2. Install the ssh build agents plugin and the configuration as code plugin
3. Define a Windows 10 agent connected over SSH using a private key credential
4. Define a long running freestyle job
5. Define another job that starts the long running freestyle job by downloading jenkins-cli.jar and using it to launch the long running job
6. Run the "starter" job and wait more than 20 minutes. Confirm that the long running job and the starter job do not fail

Most of those steps are automated by the command bash ./README.

If more details are not provided, this will be closed as "Not planned".

[daniel-beck]

Is a reverse proxy involved? What happens when you try bypassing that?

[Himanshuupadhyay398]

Hi @MarkEWaite i would love to work on this issue,
could you please assign me this issue.

[MarkEWaite]

Hi @MarkEWaite i would love to work on this issue, could you please assign me this issue.

We don't assign issues to new contributors. Please read the contributing guidelines and the issue:

• MUST READ: Instructions for newcomer contributors #26359

When you say that you want to be assigned an issue that has not been duplicated, it indicates to me that you're not spending the effort to duplicate the issue before asking that it be assigned to you. That's a bad pattern. We're much more interested in solving problems than in assuring that problems have someone assigned to them. In order to solve a problem, we need to duplicate the problem. We haven't duplicated this problem yet. We would have no way of evaluating a fix to decide if it resolved the problem.

[preetham-18-developer]

hey @MarkEWaite is anyone working on this issue

[Himanshuupadhyay398]

I spent some time trying to reproduce this on a clean Jenkins 2.541.2 setup.

I created a freestyle job and tested jenkins-cli.jar build <job> -s over HTTP. I tried builds running for about 2 minutes and about 10 minutes. In both cases the CLI waited for completion and returned SUCCESS. I wasn't able to reproduce the reported ERROR: null or see the build get aborted.

While investigating, I traced the code path through FullDuplexHttpService and noticed the 15-second CONNECTION_TIMEOUT introduced with SECURITY-3630. However, my local testing doesn't currently show it affecting long-running builds.

Could the reporter share a few more details about the environment?

• Is Jenkins behind a reverse proxy or load balancer?
• Does the issue still occur when connecting directly to Jenkins?
• About how long does the build run before it is aborted?
• What are the exact plugins installed and their versions? (use the script from "How to report an issue")

So far I haven't been able to reproduce the issue on a fresh Jenkins 2.541.2 installation.

[preetham-18-developer]

Hi @Himanshuupadhyay398,

I have started investigating this issue. I'll try to reproduce it in my local environment and will share my findings once I have more information.

[MarkEWaite]

@rshmanuka24 there are now 4 people that have asked questions and offered help on this issue report. You have not replied to any of them. Open source software issue reports work best when the submitter responds to questions from the volunteers that offer help.

[preetham-18-developer]

I tested this on a local Jenkins instance built from the current source and was unable to reproduce the issue.

I created a freestyle job and triggered it using the CLI over HTTP with the -s option. The CLI waited for the build to complete and returned:

Started test-cli #2
Completed test-cli #2 : SUCCESS

I did not observe ERROR: null or see the build being aborted.

Could you share any additional details about the environment where the issue occurs? For example, does it happen only for long-running builds, and are there any reverse proxies, load balancers, or network components between the CLI client and Jenkins?