Details
-
Bug
-
Status: Resolved (View Workflow)
-
Major
-
Resolution: Fixed
-
Jenkins 1.522 on Ubuntu 13.04, nodes on solaris sparc, solaris x86 and redhat linux.
Description
Since we upgraded from Jenkins 1.520 to 1.522 the Clock Difference is broken on the Manage Nodes page. Master and all slaves are in sync but Jenkins reports something completely different. Master and any slave running on the same server as master is reported correctly.
We have 3 Jenkins servers displaying the same symptoms.
Attachments
Issue Links
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
Activity
Richard Mortimer
added a comment - Looks like this is caused by the fix for JENKINS-18438
https://github.com/jenkinsci/jenkins/commit/735713801b130fe247cf17bbca7b4561e41b1d13
Richard Mortimer
added a comment - Looks like this is caused by the fix for JENKINS-18438
https://github.com/jenkinsci/jenkins/commit/735713801b130fe247cf17bbca7b4561e41b1d13 Integrated in 
jenkins_main_trunk #2706
[FIXED JENKINS-18671] Clock Difference broken on Manage Nodes page (Revision da9c2c55c1962dc805a3bc74f7950379371dab98)
Result = SUCCESS
richm : da9c2c55c1962dc805a3bc74f7950379371dab98
Files :
- changelog.html
- core/src/main/java/hudson/model/Slave.java
Kevin Phillips
added a comment - Can anyone tell me whether this change has been backported to the LTS release branch? We just upgraded our Jenkins master and slaves to the latest LTS edition (1.609.1) and it appears we are experiencing the same problem as described here.
As previously mentioned, all of our agents including the master are being synchronized to the same NTP server and visual confirmation of the system time as reported by the OS does show that the master is in sync with the agents (to within 1 second anyway) so it appears the information presented on the dashboard is actually incorrect.
Kevin Phillips
added a comment - Can anyone tell me whether this change has been backported to the LTS release branch? We just upgraded our Jenkins master and slaves to the latest LTS edition (1.609.1) and it appears we are experiencing the same problem as described here.
As previously mentioned, all of our agents including the master are being synchronized to the same NTP server and visual confirmation of the system time as reported by the OS does show that the master is in sync with the agents (to within 1 second anyway) so it appears the information presented on the dashboard is actually incorrect. Kevin Phillips
added a comment - Question: is it possible that this defect could also be causing an "out of order builds" problem as described by JENKINS-18289? Ever since we've upgraded to the latest LTS edition and discovered this time-sync problem, we've been getting dozens, if not hundreds of out-of-order build notifications a day. Seems like an odd coincidence.
I probably should also mention that due to other critical bugs introduced in 1.609.1 LTS we've been forced to downgrade to 1.596.3 LTS, and both problems (ie: slaves out of sync and out of order builds) are still present. I'm not sure if this helps isolate the cause of the problem or not.
Kevin Phillips
added a comment - Question: is it possible that this defect could also be causing an "out of order builds" problem as described by JENKINS-18289 ? Ever since we've upgraded to the latest LTS edition and discovered this time-sync problem, we've been getting dozens, if not hundreds of out-of-order build notifications a day. Seems like an odd coincidence.
I probably should also mention that due to other critical bugs introduced in 1.609.1 LTS we've been forced to downgrade to 1.596.3 LTS, and both problems (ie: slaves out of sync and out of order builds) are still present. I'm not sure if this helps isolate the cause of the problem or not.
I'm seeing the same issue on 1.522. My master and slaves all run NTP and manual inspection of times shows that each slave computer is definitely within a second of the master. The web interface shows differences around 1 month 30 days ahead or behind.
I have checked and confirmed that the slaves are running the slave.jar that is bundled with 1.522 but the problem still persists.
I have both Linux and Windows slaves and each report the same problem. All of the Linux master/slave computers are running IcedTea6 1.12.5 (java 1.6.0_27).