i have a question, i have two jenkins instances but sometimes display “Error: more than one instance sharing: $PATH”
do u known how to disable this alert? or remplace message to “reload Jenkins” on button?
i searched under jenkins component & the file that check this part is: “/lib/jen/lib/layout/breadcrumbs.js”
someone modify this part? could u help me plss =(
Jenkins does not support two instances using the same path. Don’t disable that alert. Fix the root problem by configuring each Jenkins controller to use its own dedicated home directory.
Jenkins does not support high availability. Using the same Jenkins home directory for two instances will not give you high availability. It will give you unreliability.
@MarkEWaite , when talking about running the controller on a container, automated deployments have a choice:
Stop the original container and then start the new one. Resulting in some downtime.
Start the new one, then stop the old one. Resulting in a minute or two of both running at the same time.
Some more context on my situation:
The controller container config uses remote mounts for buildsDir, workspacesDir and JENKINS_HOME.
The controller has no executors, we run all jobs on agents
Specifically I’m talking about using Amazon ECS in a configuration based on an AWS sample config. I asked a similar question there.
I’ve done some testing in the #2 mode and have not experienced any downsides: The UI remains available, existing jobs continue to run (on agents) and new jobs can be launched. I’d like to understand the risk we might be taking if we continue doing that. “Unsupported” might be something we can live with, using OSS anyway. But if there’s tangible, technical reason this will lead to issues, I’d love to learn about it.
I think that you are making a very risky trade if you choose option 2. I think that your goal is to reduce downtime. By having a minute or two of both running at the same time you are allowing a minute or two where the two running controllers could do damage. If that damage is immediately visible, you will spend more downtime investigating than you saved with the risk. If that damage is silent and you need to investigate it later, you will spend significantly more time than if you accept the brief downtime. If reliability is the goal, then I think it is a mistake to ignore a warning related to reliability.
When I see that warning, I immediately stop my controller and identify why that message was displayed. I suspect that others behave the same way that I do. I’m not interested in discovering race conditions and problems that Jenkins has warned may occur.
I suspect that the CloudBees people who have extended Jenkins to create the CloudBees High Availability implementation have identified those reasons and have applied safeguards and changes as part of their commercial product.