### Author:  [@mawinter69](https://community.jenkins.io/u/mawinter69)
#### Post date: [February 14, 2024, 8:58am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/2 "2024-02-14T08:58:39Z")
signal 11 means segmentation fault: [https://www.cyberciti.biz/tips/segmentation-fault-on-linux-unix.html](https://www.cyberciti.biz/tips/segmentation-fault-on-linux-unix.html)
Hard to tell what the problem is. But getting a segmentation fault in /bin/sh is strange.
Is it reproducible?
---
### Author:  [@surbhi](https://community.jenkins.io/u/surbhi)
#### Post date: [February 14, 2024, 12:23pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/3 "2024-02-14T12:23:41Z")
yes, it is reproducible
---
### Author:  [@R-Zwi](https://community.jenkins.io/u/R-Zwi)
#### Post date: [February 27, 2024, 7:12am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/4 "2024-02-27T07:12:26Z")
A very similar issue occours on our linux agents since some unattended linux updates today (in this example when trying to execute `println "whoami".execute().text` in the Script Console of the node):
```auto
java.io.IOException: error=0, Failed to exec spawn helper: pid: 1357112, signal: 11
at java.base/java.lang.ProcessImpl.forkAndExec(Native Method)
at java.base/java.lang.ProcessImpl.(ProcessImpl.java:314)
at java.base/java.lang.ProcessImpl.start(ProcessImpl.java:244)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1110)
Caused: java.io.IOException: Cannot run program "whoami": error=0, Failed to exec spawn helper: pid: 1357112, signal: 11
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1143)
at java.base/java.lang.ProcessBuilder.start(ProcessBuilder.java:1073)
at java.base/java.lang.Runtime.exec(Runtime.java:594)
at java.base/java.lang.Runtime.exec(Runtime.java:418)
at java.base/java.lang.Runtime.exec(Runtime.java:315)
at org.codehaus.groovy.runtime.ProcessGroovyMethods.execute(ProcessGroovyMethods.java:544)
at org.codehaus.groovy.runtime.dgm$895.invoke(Unknown Source)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274)
at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56)
at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:47)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:116)
at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:120)
at Script1.run(Script1.groovy:1)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:574)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:612)
at groovy.lang.GroovyShell.evaluate(GroovyShell.java:583)
at hudson.util.RemotingDiagnostics$Script.call(RemotingDiagnostics.java:149)
at hudson.util.RemotingDiagnostics$Script.call(RemotingDiagnostics.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:211)
at hudson.remoting.UserRequest.perform(UserRequest.java:54)
at hudson.remoting.Request$2.run(Request.java:377)
at hudson.remoting.InterceptingExecutorService.lambda$wrap$0(InterceptingExecutorService.java:78)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635)
at java.base/java.lang.Thread.run(Thread.java:840)
```
---
### Author:  [@R-Zwi](https://community.jenkins.io/u/R-Zwi)
#### Post date: [February 27, 2024, 7:53am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/5 "2024-02-27T07:53:34Z")
I was able to fix it with this option: `-Djdk.lang.Process.launchMechanism=vfork`
(as mentioned [here](https://stackoverflow.com/a/61325264/3301051))
---
### Author:  [@Dregos13](https://community.jenkins.io/u/Dregos13)
#### Post date: [February 27, 2024, 1:14pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/6 "2024-02-27T13:14:22Z")
Where can we add it in jenkins???
I need this config and saw the post. Is there like env section or something?
---
### Author:  [@R-Zwi](https://community.jenkins.io/u/R-Zwi)
#### Post date: [February 27, 2024, 1:35pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/7 "2024-02-27T13:35:17Z")
Hi @Dregos13 , it depends on your setup.
My Jenkins instance is running as a Linux service,
so I used `sudo systemctl --full edit jenkins.service` to get to the config file and added it to the `JAVA_OPTS`:
```auto
Environment="JAVA_OPTS=-Djava.awt.headless=true \
-Djdk.lang.Process.launchMechanism=vfork \
-Djenkins.model.Jenkins.buildsDir=/mydata/JenkinsJobsBuilds/\\${ITEM_FULL_NAME}/builds \
-Djenkins.model.Jenkins.workspacesDir=/mydata/JenkinsJobs/workspace/\\${ITEM_FULL_NAME} "
```
---
### Author:  [@jspiewak](https://community.jenkins.io/u/jspiewak)
#### Post date: [February 27, 2024, 9:01pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/8 "2024-02-27T21:01:40Z")
Seeing the same thing in our Jenkins infrastructure.
Some agents ran unattended updates and picked up the security updates to OpenJDK 17 (17.0.10) that were made public today, and I am suspicious that is related.
However, I cannot reliably reproduce the spawn failure (yet).
What version of the JDK are your agents running?
---
### Author:  [@jspiewak](https://community.jenkins.io/u/jspiewak)
#### Post date: [February 27, 2024, 9:34pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/9 "2024-02-27T21:34:47Z")
I _think_ that I just figured out what is provoking this issue.
If the JDK on the agent is updated via the unattended updates, but the Jenkins agent java process is _not_ restarted, the spawn error occurs.
Disconnecting the agent and re-launching allows the script console snippet to run.
---
### Author:  [@lamhaison](https://community.jenkins.io/u/lamhaison)
#### Post date: [February 28, 2024, 3:28am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/10 "2024-02-28T03:28:30Z")
In my case, I use with Jenkins controller agent on AWS with Ec2 Plugin
On the Jenkins controller, I set the setting JAVA\_OPTS=-Djava.awt.headless=true
On the Jenkins agent, I create new golden image from the agent (It run failed the jobs) and use it as the image for creating Jenkins agent in the next time
It is working well at the moment
---
### Author:  [@mbraunerDE](https://community.jenkins.io/u/mbraunerDE)
#### Post date: [February 28, 2024, 7:03am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/11 "2024-02-28T07:03:14Z")
Thank you, that solved my pain!
---
### Author:  [@R-Zwi](https://community.jenkins.io/u/R-Zwi)
#### Post date: [February 28, 2024, 7:10am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/12 "2024-02-28T07:10:38Z")
Yes, there was (among others) a change in the version of the package `openjdk-17-jre-headless:amd64`:
from `17.0.9+9-1~22.04` to `17.0.10+7-1~22.04.1`
and the issue didn’t occour on the nodes that where still on `17.0.9+9-1~22.04`
---
### Author:  [@rgledhill](https://community.jenkins.io/u/rgledhill)
#### Post date: [February 28, 2024, 10:42am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/13 "2024-02-28T10:42:52Z")
We had this unwelcome behaviour this morning for no obvious reason - the Jenkins Controller was simply trying to execute git to retrieve a JenkinsFile from the repository.
After much digging around and confirming that the jspawn file exists etc etc… I simply restarted Jenkins and now it’s working fine.
You can do this via the web interface or do:
sudo systemctl stop jenkins
sudo systemctl start jenkins
---
### Author:  [@greggles](https://community.jenkins.io/u/greggles)
#### Post date: [February 28, 2024, 3:41pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/14 "2024-02-28T15:41:03Z")
This problem cropped up for my team yesterday. We use Jenkins on ubuntu 22.04. Many builds ran fine and then several failed quickly with this error yesterday morning. We restarted Jenkins and builds ran fine for about 24 hours until they started failing with the same error. We have not manually done updates recently, but I’m curious what folks mean by “Some agents ran unattended updates” - does Ubuntu 22.04 automatically update itself?
Our openjdk-17-jre-headless version is 17.0.10+7-1~22.04.1
We followed instructions here:
1. `sudo systemctl --full edit jenkins.service`
2. Find the line with JAVA\_OPTS
3. Add in a new line: ` \ -Djdk.lang.Process.launchMechanism=vfork "`
4. stop jenkins service `sudo systemctl stop jenkins`
5. start jenkins service `sudo systemctl start jenkins`
I’m surprised there’s not a new Jenkins package to incorporate this fix.
---
### Author:  [@jspiewak](https://community.jenkins.io/u/jspiewak)
#### Post date: [February 28, 2024, 7:28pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/15 "2024-02-28T19:28:23Z")
Modern versions of Ubuntu, by default, will perform unattended updates for packages with security fixes.
We have a fleet of agents that auto-scale. The AMI that they launch had OpenJDK 17.0.9. If the agent was up and in use long enough, the unattended update would update the OpenJDK package. This had the effect of deleting the existing files/directories, but left the agent process running. When that agent process attempts to use jspawnhelper, it is no longer present where it thinks it should be, and boom!
Our solution was to update our AMI to `apt-mark hold` the OpenJDK package so that the unattended updates should no longer affect it. We have a regular schedule of updating the AMI to pick up security updates and such, so we are not concerned about that aspect.
---
### Author:  [@R-Zwi](https://community.jenkins.io/u/R-Zwi)
#### Post date: [March 1, 2024, 7:36am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/16 "2024-03-01T07:36:40Z")
After updating another machine I can confirm what was mentioned in [this post](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/9): simply disconnecting and reconnecting the node fixes the issue.
This time the issue occoured although `-Djdk.lang.Process.launchMechanism=vfork` had already been in place, so it effectively doesn’t fix it. So I removed this setting and everything is still working fine.
---
### Author:  [@R-Zwi](https://community.jenkins.io/u/R-Zwi)
#### Post date: [March 1, 2024, 9:59am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/17 "2024-03-01T09:59:07Z")
for the records:
see also [Loading...](https://issues.jenkins.io/browse/JENKINS-72665)
and [Bug #2055280 “openjdk-17-jre-headless 17.0.10+7-1~22.04.1: segfa...” : Bugs : openjdk-17 package : Ubuntu](https://bugs.launchpad.net/ubuntu/+source/openjdk-17/+bug/2055280)
---
### Author:  [@Bharath547](https://community.jenkins.io/u/Bharath547)
#### Post date: [March 8, 2024, 6:16am UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/18 "2024-03-08T06:16:14Z")
Thanks. Just restarting jenkins service in the linux agent resolved the issue
---
### Author:  [@ChrisZ62](https://community.jenkins.io/u/ChrisZ62)
#### Post date: [June 25, 2024, 11:16pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/19 "2024-06-25T23:16:18Z")
How will this work if Jenkins is run as a Docker container? We don’t run jobs on the controller, only on build slaves and am getting this error. I asked the question in Stack Overflow
>
---
### Author:  [@MarkEWaite](https://community.jenkins.io/u/MarkEWaite)
#### Post date: [June 25, 2024, 11:58pm UTC](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460/20 "2024-06-25T23:58:19Z")
> [@ChrisZ62](#):
>
> We don’t run jobs on the controller, only on build slaves and am getting this error
If you’re running the jobs on a static agent that is having its Java version upgraded while the agent is running, then that is the likely cause of the problem. Changing the Java property seems to be hiding the danger that you’re upgrading the Java installation of a running agent.
If you’re running the jobs on an agent defined with a container, then something seems wrong in the agent. A containerized agent should not have the issue because the version of Java in the containerized agent should not change while the agent is running.
[Next page](https://community.jenkins.io/t/jenkins-issue-fatal-command-execution-failed/12460.md?page=2)