Unable to add new Bitbucket linked repositories in Bamboo with error "com.atlassian.bamboo.executor.CancelException: /usr/bin/git could not be started"
Platform Notice: Data Center Only - This article only applies to Atlassian apps on the Data Center platform.
Note that this KB was created for the Data Center version of the product. Data Center KBs for non-Data-Center-specific features may also work for Server versions of the product, however they have not been tested. Support for Server* products ended on February 15th 2024. If you are running a Server product, you can visit the Atlassian Server end of support announcement to review your migration options.
*Except Fisheye and Crucible
Summary
Summary
When adding a new Bitbucket-linked repository in Bamboo, the following error can be seen in the User Interface:
com.atlassian.bamboo.executor.CancelException: /usr/bin/git could not be started: command [/usr/bin/git version] failed with code -1. Working directory was [/]. []Existing linked repositories remain functional.
Environment
Observed on Bamboo 9.6.2, but may be applicable to other supported versions.
Diagnosis
When adding a new Bitbucket-linked repository in Bamboo, the following errors can be seen on the page:
New access key is required but could not be added to Bitbucket Server.
com.atlassian.bamboo.executor.CancelException: /usr/bin/git could not be started: command [/usr/bin/git version] failed with code -1. Working directory was [/]. []When checking the Bamboo logs at <bamboo-home>/logs/atlassian-bamboo.log the following error is present:
java.io.IOException: Cannot run program "/GIT/PATH/git": error=0, Failed to exec spawn helper: pid: <PID>, exit value: 1By checking the Operating System's unattended upgrades log files, there's evidence of an unattended upgrade of the JDK packages:
unattended-upgrades.logs
2024-06-06 06:04:55,151 INFO Packages that will be upgraded: ... openjdk-17-jdk openjdk-17-jdk-headless openjdk-17-jre openjdk-17-jre-headless ...
2024-06-06 06:04:55,151 INFO Writing dpkg log to /var/log/unattended-upgrades/unattended-upgrades-dpkg.log
2024-06-06 06:06:12,998 INFO All upgrades installed
The location of the unattended upgrade logs may vary according to your Operating System. Please validate with a System Administrator. Example locations:
/var/log/apt/history.log/var/log/unattended-upgrades/unattended-upgrades-dpkg.log
Cause
Unattended upgrades of Java
This issue is caused by an unattended Java upgrade that includes changes to the JSpawnHelper tool, a component critical for spawning processes from Java applications. This upgrade, performed without a corresponding restart of the Bamboo service (and any other Java processes), leads to inconsistencies between the Bamboo application's runtime environment and the underlying JDK. Consequently, Bamboo's attempts to invoke Git operations fail due to incompatible changes in the JDK's process handling mechanisms.
File Permission
The file permissions inside the JAVA_HOME/lib/ and especially the jspawnhelper tool: The tool needs to have executable permission for Bamboo to execute any programs like git, bash, etc.
Solution
Unattended upgrades of Java
Restart the Bamboo service/process. The immediate resolution involves restarting Bamboo, which allows the application to initialize with the updated JDK, aligning the runtime environment with the upgraded JDK's expectations and capabilities. Additionally, we would advise disabling unattended upgrades.
Detailed Steps:
Restart the Bamboo service/process
Disable Unattended Upgrades Execute the following command to remove unattended upgrades:
sudo apt remove unattended-upgradesExclude JDK from Automatic Upgrades Edit the Unattended-Upgrades configuration file to blocklist JDK packages:
sudo nano /etc/apt/apt.conf.d/50unattended-upgradesAdd the following to the
Unattended-Upgrade::Package-Blacklistsection:Unattended-Upgrade::Package-Blacklist { "openjdk-17-jdk-headless"; "openjdk-17-jre-headless"; "openjdk-17-jdk"; "openjdk-17-jre"; };
Please keep in mind that these suggestions involve changes to the operating system, which aren't covered by our support. It might be helpful to collaborate with your administration team to review these options.
File Permissions
Provide executable permission to the files inside JAVA_HOME/lib/ and especially the jspawnhelper tool for example: 755
You might also ensure that the JAVA_HOME variable is correctly set: Setting JAVA_HOME.
To prevent similar occurrences, it's recommended to review the settings for unattended upgrades, particularly for critical components like the JDK. Ensuring that automatic updates are either carefully managed or that post-upgrade restarts of dependent services are automated can mitigate downtime and functionality issues.
Was this helpful?