This happens when you run a sh step?
You might want to set org.jenkinsci.plugins.durabletask.BourneShellScript.USE_BINARY_WRAPPER=true via script console or permanently as a java property in the java command that starts jenkins (java -Dorg.jenkinsci.plugins.durabletask.BourneShellScript.USE_BINARY_WRAPPER=true ... -jar jenkins.war ...)
We also use RHEL8.9 agents with JDK21. We’ve been using this setup without issue for approximately 2 months. We’re on Jenkins 2.463 and have upgraded a couple of times in the last few months. We just started seeing the same error about nohup, but it only appears intermittently. Some builds run without issue, others throw an exception when using sh.
Is there any additional information on this issue?
edit: downgrading RHEL8 agents to JDK17 appears to have fixed the issue for us.
Some additional info, after downgrading to JDK 17 the issue was resolved for approximately one day and then later resurfaced. We use GCP VMs running RHEL8 as Jenkins agents. These are created by Jenkins from an image. The image had JDK version 17.0.11 installed. Jenkins picks up this version of the JDK. dnf-automatic was installed on the VMs, and after about 5 minutes of uptime dnf-automatic was upgrading the JDK version to 17.0.12, but Jenkins already read the version as 17.0.11. Removing dnf-automatic so the JDK version remains at 17.0.11 appears to have fixed the problem
Hi, same here, rhel8 and rhel9.
With JDK 17.0.12 all my pipelines break with nohup not being able to run, while 17.0.11 works fine.
Is that more a java or a jenkins issue? Or even a security policy thingy?
Thanks for the advice! This does maybe seem to get me past the ‘nohup’ issue, but I am now running into similar issues:
Contxt: I re-upgraded to 21 around July 2nd. For a month, all seemed well. However, yesterday, I am starting to see issues with Java 21 not finding executables again! Specifically, this morning I am seeing that Jenkins is unable to find the following executables so far:
nohup
cp
python3.11
I was surprised that org.jenkinsci.plugins.durabletask.BourneShellScript.USE_BINARY_WRAPPER=true did seem to get me past the nohup issue, but now I am running into issues with cp and python3.11 being unavailable (but they certainly are available. I’ve confirmed the jenkins user can indeed run cp and python3.11 on my agents.)
Do you have by chance automatic updates enabled for java in your package manager and java was updated but your agents were not restarted?
See 2 comments above from @ciaconet
There is a chance that it has something to do with java being updated automatically via our patching process. I can look more into this.
I will try restarting my Jenkins Controller entirely, which I believe should have the effect of restarting all of the agents as well.
Note: I am debugging this and it seems that even the most simple pipeline is failing to run due to: Caused: java.io.IOException: Cannot run program "/var/lib/jenkins/caches/durable-task/durable_task_monitor_555.v6802fe0f0b_82_linux_64" (in directory "/var/lib/jenkins/workspace/tinker"): error=2, No such file or directory"
Per @mawinter69, I checked if Java 21 was recently updated. It does indeed seem that it was which does correspond to the issues I’ve been seeing most recently!
$ yum history | head
Not root, Subscription Management repositories not updated
ID | Command line | Date and time | Action(s) | Altered
------------------------------------------------------------------------------------------------
... trimmed for brevity...
142 | -d 0 -e 1 -y upgrade java-21-openjdk | 2024-08-06 02:02 | Upgrade | 2
... trimmed for brevity...
My agents are running RedHat Enterprise Linux 8 and 9.
