I think this is simply because the agent process survives the master
restart (that is actually a feature) so if agent settings change, you need
to disconnect and connect the agent (or otherwise restart the agent process
to pick up the changes).
timb...@gmail.com schrieb am Freitag, 25. September 2020 um 20:03:25 UTC+2:
> Thanks. I believe you were saying stop/start because you're using Docker
> container. In your Docker example, stopping and restarting the Docker
> container is analogous to rebooting (power cycling, or sudo rebooting) the
> physical or virtual machine hosting the Jenkins service.
>
> In this thread I'm saying that restarting the Jenkins service (which
> resides within a container or vm that is NOT being restarted/rebooted) IS
> sufficient to apply MOST CasC settings, however, NOT the ssh agent
> jvmOptions. It's not a blocking problem, bc I can get the desired effect by
> rebooting master/controller and agent machines. But it's a mystery I'd like
> to understand better, bc as I scale this cluster and rll out new
> configuration changes to it, I'm going to need to understand these
> mechanics.
>
> Would this be an appropriate thread for jenkins-developers group? Is there
> another forum you could recommend to ask detailed questions about JCasC?
> (I'm on the gitter channel but it's quite hit and miss due to the format)
>
> On Friday, September 25, 2020 at 8:56:43 AM UTC-7 kuisat...@gmail.com
> wrote:
>
>> Restart Jenkins using the CLI(
>> https://www.jenkins.io/doc/book/managing/cli/) it is the same make it
>> from the UI. When I said stop/start, I mean stop/start the Jankins
>> daemon/service/Docker container/Whatever. The reason it is because IIRC
>> JCasC runs on the start time of the Jenkins process, and also IIRC if you
>> make changes on the JCasC config file and reload the configuration, or
>> restart from UI the JCasC configuration is not recreated because the stage
>> where it is run is not running on those restart ways. Probably someone with
>> the deepest acknowledge of JCasC can add more context.
>> It is easy to check, run a Jenkins Docker container configured with
>> JCasC (e.g.
>> https://github.com/kuisathaverat/jenkins-issues/tree/master/JENKINS-63703)
>> then connect to the container and modify the JENKINS_HOME/jenkins.yaml file
>> and restart from UI or CLI, the JCasC changes will not apply if you stop
>> the Docker container and start it again the changes are applied.
>>
>> El vie., 25 sept. 2020 a las 17:33, Tim Black ()
>> escribió:
>>
>>> Thanks. What's the difference between "restart Jenkins from UI" and
>>> "stop the Jenkins instance and start it again"? In the latter, how are you
>>> implying that Jenkins gets stopped and restarted, through the CLI? Just
>>> trying to understand what you're saying - it sounds like you're implying
>>> CasC settings aren't applied when you restart jenkins through the GUI, but
>>> they are when you restart through the CLI..
>>>
>>> I don't think this explanation is relevant to my use case bc I *never*
>>> restart
>>> jenkins through the GUI. In the workflow I outlined above, I am running an
>>> ansible playbook on my jenkins cluster, over and over, and each time if
>>> there is a config change, it restarts the jenkins service through the CLI
>>> using a jenkins admin credentials (using an active-directory user
>>> actually). This appears to *not *have the desired effect of applying
>>> the new agent jvmOptions upon next connection of the agent, whereas when I
>>> simply reboot the entire machines (master/controller and agents), the new
>>> jvmOptions are used in the SSHLauncher). Note that *I do not have this
>>> same problem with other CasC settings, only ssh agents.*
>>>
>>> On Friday, September 25, 2020 at 3:05:59 AM UTC-7 kuisat...@gmail.com
>>> wrote:
>>>
ok, I think I know what happens, I saw it before using Docker and
JCasC, if you make changes on the JCasC and restart Jenkins from UI the
changes are not applied because JCasC is not executed on that restart, but
if you stop the Jenkins instance and start it again the changes are
applied
IIRC is how it works.
El miércoles, 23 de septiembre de 2020 a las 23:37:18 UTC+2, Ivan
Fernandez Calvo escribió:
> I will configure a test environment with JCasC that has jmvOptions too
> see how it behaves, then we will know if it is an issue or not, in any
> case
> is weird.
>
> El El mié, 23 sept 2020 a las 22:10, Tim Black
> escribió:
>
>> More info: In my case, a reboot is definitely needed. A
>> disconnect/reconnect does not suffice, nor does rebooting just the
>> master/controller or the agent in sequence - *the only way I see the
>> correct jvmOptions being used is by rebooting the entire cluster at once*
>> .
>>
>> I'm using Jenkins 2.222.3, ssh build agents plugin 1.31.2.
>>
>> Another probably important
