Are you manually modifying the config.xml while Jenkins is running, or is this change only your observation because your view config is reset upon restart?

I am not manually modifying the config.xml while jenkins is running. I backed up the config before I did a restart so I could compare the two files. The result is what you see above.

Also, when I make the changes through the UI then view the xml I see what I would expect to be there, but when I restart it is gone again. It does seem to be limited to just these two config values, Views and the Slave port. Everything else persists correctly.

Is there a file named init.groovy, or a folder init.groovy.d in the Jenkins home directory? If so, what are the contents?

Is security in Jenkins enabled?

Security is enabled. I am using Jenkins user database along with the Role Strategy Plugin. https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin

I do not see any init.groovy or a init.groovy.d folder

Is JobConfigHistory plugin installed, and if so, does it record changes to the global config.xml? Which user is specified?

It is not installed... but if it would be helpful I could install it.

@Joseph
Any updates?

We are experiencing a similar issue. We have recently upgraded from Jenkins 1.480.3 to 1.565.3 and it seems once any change is made to the global config.xml file by jenkins, it looses all configurations from the views section forward including our Global Environment Variables section.

We have the JobConfigHistory plugin installed and it only shows that SYSTEM is making the changes to the config file.

We have been working on this issue for several days now and have spun up a couple of test environments. We cannot seem to reproduce this issue consistently in our test environments.

We have tailed stderr and stdout and have observed no exceptions on startup or restart of Jenkins

Here are the steps to reproduce our issue (in one environment anyways)

• Take a config file from a jenkins that is not showing the views and copy it into test environment master-workspace
• Start up jenkins and verify that Views and Environment variables are not displayed in the UI
• Verify that Views and Environment variables are still in the config.xml file
• Change the System Message of the Jenkins Server in Jenkins->Configuration
• Click Save
• Observe that the Views section and Environment Variable section of config.xml are now clobbered. (No Views, No Environment Variables)

Any thoughts?

amberkorey: I suggest checking 'Manage Old Data' to make sure no plugins are misbehaving.

As your observed behavior is quite different, it appears to be unrelated to the issue reported and investigated here. Please ask e.g. in IRC or on the jenkinsci-users list for troubleshooting advice.

I am still seeing the same issue. The comment above is almost exactly what I see. System is making the cahnge

@Joseph, which Jenkins version are you using?

Update:

We ran the 'Manage Old Data' tool and it was complaining about a tag in our EC2 Slave node (hudson.plugins.ec2.EC2Slave). The exact error message was:

ConversionException: No field 'autoConstruct' found in class 'com.amazonaws.internal.ListWithAutoConstructFlag' : No field 'autoConstruct' found in class 'com.amazonaws.internal.ListWithAutoConstructFlag' ---- Debugging information ---- message : No field 'autoConstruct' found in class 'com.amazonaws.internal.ListWithAutoConstructFlag' cause-exception : com.thoughtworks.xstream.converters.reflection.MissingFieldException cause-message : No field 'autoConstruct' found in class 'com.amazonaws.internal.ListWithAutoConstructFlag' class : com.amazonaws.internal.ListWithAutoConstructFlag required-type : com.amazonaws.internal.ListWithAutoConstructFlag converter-type : com.thoughtworks.xstream.converters.reflection.SerializableConverter path : /hudson/slaves/hudson.plugins.ec2.EC2Slave/lastFetchInstance/tags/com.amazonaws.internal.ListWithAutoConstructFlag/default/autoConstruct line number : 2431 -------------------------------, MissingFieldException: No field 'securityGroups' found in class 'hudson.model.Hudson', MissingFieldException: No field 'hypervisor' found in class 'hudson.model.Hudson', MissingFieldException: No field 'ebsOptimized' found in class 'hudson.model.Hudson'

We took out the tag and now empty surrounding tags from all ec2 slave nodes listed in config.xml and restart Jenkins. Our views and our environment variables were back in the UI.

So now we are tracking down how the autoConstruct tag made it into our config.xml in the first place.

It looks like there is an xml section called lastFetchInstance that is present in our bad configs but not our good configs. We are not sure what creates that section at this point but will keep updating the thread as things progress.

I am using Jenkins 1.582. I also have the ec2 plugin installed but do not have anything come up in the managed old data. For me I notice that the Views and the Jenkins Slave port are the two pieces of data that consistently disappear on reboots. I have started uninstalling any non essential plugins but have not seen any changes yet. I need the ec2 plugin so unfortunately uninstalling it is not an option.

I am using version 1.24 of the ec2 plugin.

<com.amazonaws.internal.ListWithAutoConstructFlag>
<default>
<autoConstruct>true</autoConstruct>
</default>
</com.amazonaws.internal.ListWithAutoConstructFlag>
</blockDeviceMappings>

This is where I see autoConstruct in my config. I see the autoConstruct tag all over the ec2 config. Of course this is not causing any errors in my config to come up in "Manage Old Data" and the xml seems valid.

Code changed in jenkins
User: Francis Upton
Path:
src/main/java/hudson/plugins/ec2/EC2AbstractSlave.java
http://jenkins-ci.org/commit/ec2-plugin/d823b5e5da73f2ea9f57f11d890246df5f6c5110
Log:
Merge pull request #112 from jglick/transient-lastFetchInstance

JENKINS-24938 Various fields should be transient

Compare: https://github.com/jenkinsci/ec2-plugin/compare/7ebb4886cc05...d823b5e5da73

@Francis Upton
Can you kindly explain why changing the fields to be transient will solve the issue?

Cheers,
Amber & Korey Pairing (Our old account got locked out).

Transient fields don't get serialized to XML on disk by Xstream.

I have tested the fix and it works. Basically Xstream was not deserializing some values correctly and those values were not meant to be persisted in the first place.

I have updated my masters with the patch and the fix works.

We have installed the EC2 plugin with these changes and we are not seeing this problem anymore!

Thank you!

When will the next release of the Amazon EC2 plugin be available?