• Icon: Bug Bug
    • Resolution: Fixed
    • Icon: Major Major
    • core
    • Jenkins 1.522 on Ubuntu 13.04, nodes on solaris sparc, solaris x86 and redhat linux.

      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.

          [JENKINS-18671] Clock Difference broken on Manage Nodes page

          Same here: one node is 15 mins ahead, the other one is 4d 16h ahead.
          Is it possible that this is related to remote file system problems e.g. described in 10771?

          Marcel Beister added a comment - Same here: one node is 15 mins ahead, the other one is 4d 16h ahead. Is it possible that this is related to remote file system problems e.g. described in 10771?

          Andréas Berg added a comment -

          This issue appeared for us after upgrading from 1.520 to 1.522. I've never seen this behaviour before so I doubt its realted to #10771 as that issue has existed for almost two years.

          Andréas Berg added a comment - This issue appeared for us after upgrading from 1.520 to 1.522. I've never seen this behaviour before so I doubt its realted to #10771 as that issue has existed for almost two years.

          A manual refresh is done almost instantly, the time difference remains the same here.

          Marcel Beister added a comment - A manual refresh is done almost instantly, the time difference remains the same here.

          same here, time differences between "3 mo 7 days behind" to "43 years ahead" .

          Florian Doersch added a comment - same here, time differences between "3 mo 7 days behind" to "43 years ahead" .

          Marcel Beister added a comment - - edited

          @Andréas Berg: #10771 can have multiple reasons that lead to the same problem (remote-fs error) and differences in system time can lead to errors in network communication. Maybe there is also an error if the system just thinks that the system time is different, but I'm also not really convinced regarding that theory

          Marcel Beister added a comment - - edited @Andréas Berg: #10771 can have multiple reasons that lead to the same problem (remote-fs error) and differences in system time can lead to errors in network communication. Maybe there is also an error if the system just thinks that the system time is different, but I'm also not really convinced regarding that theory

          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).

          Richard Mortimer added a comment - 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).

          Richard Mortimer added a comment - Looks like this is caused by the fix for JENKINS-18438 https://github.com/jenkinsci/jenkins/commit/735713801b130fe247cf17bbca7b4561e41b1d13

          dogfood added a comment -

          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

          dogfood added a comment - 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

          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.

          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.

            Unassigned Unassigned
            epkabeg Andréas Berg
            Votes:
            14 Vote for this issue
            Watchers:
            19 Start watching this issue

              Created:
              Updated:
              Resolved: