Document -XX:OnOutOfMemoryError as a way to recover from a crashed agent JVM - #1001
Open
om7057 wants to merge 1 commit into
Open
Document -XX:OnOutOfMemoryError as a way to recover from a crashed agent JVM#1001om7057 wants to merge 1 commit into
om7057 wants to merge 1 commit into
Conversation
…ent JVM Issue jenkinsci#775 reports that an agent whose JVM runs out of memory on the remote machine stays connected in a broken state and keeps failing every build routed to it, since nothing on the Jenkins side detects that the process is no longer functioning correctly. The jvmOptions field already passes its value straight into the remote java invocation used to launch the agent (SSHLauncher.java, getWorkDirParam/launch command construction), so users can already add -XX:OnOutOfMemoryError="kill -9 %p" or -XX:+ExitOnOutOfMemoryError today to make the JVM terminate immediately on OOM, which lets Jenkins detect the disconnect and retry the launch instead of leaving a dead agent in rotation. The field's help text never mentioned this, and predates this being a documented option. This documents the existing mechanism so users encountering jenkinsci#775 have an immediate mitigation without needing a plugin code change, since the operating system and JVM already handle this case more reliably than reimplementing OOM detection in the plugin would. Relates to jenkinsci#775
There was a problem hiding this comment.
Pull request overview
Updates the SSH agent JVM options help text to document JVM flags that force agent termination on OutOfMemoryError, mitigating cases where an OOM’d agent stays “connected” but non-functional (as described in #775).
Changes:
- Expanded
help-jvmOptions.htmlto mention-XX:OnOutOfMemoryError="kill -9 %p"and-XX:+ExitOnOutOfMemoryErroras mitigation options for crashed/broken agent JVMs.
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Relates to #775
Issue #775 reports that an agent whose JVM runs out of memory on the remote machine stays connected in a broken state and keeps failing every build routed to it, since nothing on the Jenkins side detects that the process is no longer functioning correctly.
I checked whether the two "possible solutions" listed in the issue (monitor exceptions and kill the process, or add a JVM flag to exit on OOM) require a plugin code change, and the second one does not. The
jvmOptionsfield already passes its value straight into the remote java invocation used to launch the agent (SSHLauncher.java, the command built in the launch method), so users can already add-XX:OnOutOfMemoryError="kill -9 %p"or-XX:+ExitOnOutOfMemoryErrortoday. Either makes the JVM terminate immediately on OOM, which lets Jenkins detect the disconnect and retry the launch instead of leaving a dead agent in rotation. The field's help text never mentioned this option, and predates it being documented anywhere in the plugin.This is a documentation-only change to
help-jvmOptions.html, so users encountering #775 get an immediate mitigation without needing to wait on a plugin release. I don't think this fully closes #775, since it doesn't add any proactive detection on Jenkins' side for users who don't set this flag, so I left it as "Relates to" rather than "Fixes". Happy to look at a more proactive code-level fix (the issue's first suggested direction) if maintainers think this documentation mitigation isn't sufficient, but wanted to land the low-risk, immediately actionable part first.Testing done
Documentation-only change, verified the rendered help text by building the plugin and inspecting the generated
SSHConnector/help-jvmOptions.htmloutput. Also confirmedgetJvmOptions()is used directly in the launch command construction inSSHLauncher.javabefore writing this, so the documented flags are actually effective.Submitter checklist