Start Jenkins with java -jar jenkins-2.0-beta-1.jar on windows

      In the console hit ctrl+c

      expected behaviour

      Jenkins does a graceful shutdown and this is appropriately logged

      actual behaviour

      it appears as though Jenkins is brutally terminated and does not do a graceful shutdown.
      There are no logs to indicate a graceful termination

      In 1.x I see the following logs
      Mar 31, 2016 12:02:39 PM winstone.Logger logInternal INFO: JVM is terminating. Shutting down Winstone

      in 2.x I do not see those entries - and there is nothing to indicate in the log that Jenkins is shutting down gracefully

          [JENKINS-33926] Jenkins no longer appears to shutdown correctly

          James, I'm sending it over to you since I couldn't reproduce it on beta while Ctrl-C or while stopping the service. I'm going to see if I can reproduce it on the RC, but I must not be going through the correct steps or something.

          Note: the part about losing the job queue when restarted as a Windows service looks like an older problem. I definitely think that this should be a bug if it's not already.

          Kristin Whetstone added a comment - James, I'm sending it over to you since I couldn't reproduce it on beta while Ctrl-C or while stopping the service. I'm going to see if I can reproduce it on the RC, but I must not be going through the correct steps or something. Note: the part about losing the job queue when restarted as a Windows service looks like an older problem. I definitely think that this should be a bug if it's not already.

          Sam, it sounds like your defect is something different than what the original problem covered by this work item. While the queue is saved, it's not saving everything. That might be a bug in the queue.save(). In the Windows version it's not getting saved at all during Ctrl-C. We should open a ticket for that problem so it could be fixed.

          Kristin Whetstone added a comment - Sam, it sounds like your defect is something different than what the original problem covered by this work item. While the queue is saved, it's not saving everything. That might be a bug in the queue.save(). In the Windows version it's not getting saved at all during Ctrl-C. We should open a ticket for that problem so it could be fixed.

          Sam Van Oort added a comment -

          Yeah, I can't tell for sure if it's the same issue, something similar, or these are all different manifestations of the same underlying cause.

          The previous issue with losing the build queue apparently had some sort of handling with nextBuildNumber that resolved it (I think?). This one seems to be some combination of shutdown logging & queue writing, which could also be two separate issues as well.

          Sam Van Oort added a comment - Yeah, I can't tell for sure if it's the same issue, something similar, or these are all different manifestations of the same underlying cause. The previous issue with losing the build queue apparently had some sort of handling with nextBuildNumber that resolved it (I think?). This one seems to be some combination of shutdown logging & queue writing, which could also be two separate issues as well.

          To me, the file showing up in the first place and that it's successfully read on startup means the file was created correctly (there's no missing information when being written and it's not formatted incorrectly) it might just be incomplete. Obviously I'm making some assumptions on the queue behavior, and spent some time trying to go through where the queue was written so figure out how it came into being. Apparently there are 2 types of shutdown: one that writes the queue and one that's "quick" not counting the error case, the secret not-so-fun shutdown. From what I understand the error case just completely tanks jetty, et al. If it's able to save state enough to pick back up on a restart, I think that's slightly better than not having anything at all.

          I'd check out if the queue being incomplete issue exists on the latest 1.x release. That will at least give some context into whether it's something new or not. Either way it's not good, but at least it's not worse!

          Kristin Whetstone added a comment - To me, the file showing up in the first place and that it's successfully read on startup means the file was created correctly (there's no missing information when being written and it's not formatted incorrectly) it might just be incomplete. Obviously I'm making some assumptions on the queue behavior, and spent some time trying to go through where the queue was written so figure out how it came into being. Apparently there are 2 types of shutdown: one that writes the queue and one that's "quick" not counting the error case, the secret not-so-fun shutdown. From what I understand the error case just completely tanks jetty, et al. If it's able to save state enough to pick back up on a restart, I think that's slightly better than not having anything at all. I'd check out if the queue being incomplete issue exists on the latest 1.x release. That will at least give some context into whether it's something new or not. Either way it's not good, but at least it's not worse!

          Sam Van Oort added a comment -

          Oh! I'd tested on CJE 1.625.16.1 - the queue is maintained when killed by Ctrl+C. Just rechecked, and that is also true on 1.642.x - so it's clearly a regression since then.

          To be clear: we're not saving state to pick back up on restart at all. The queue.xml is empty of items, this is one sample:

          <?xml version='1.0' encoding='UTF-8'?>
          <hudson.model.Queue_-State>
            <counter>42</counter>
            <items/>
          </hudson.model.Queue_-State>
          

          Sam Van Oort added a comment - Oh! I'd tested on CJE 1.625.16.1 - the queue is maintained when killed by Ctrl+C. Just rechecked, and that is also true on 1.642.x - so it's clearly a regression since then. To be clear: we're not saving state to pick back up on restart at all. The queue.xml is empty of items, this is one sample: <?xml version= '1.0' encoding= 'UTF-8' ?> <hudson.model.Queue_-State> <counter>42</counter> <items/> </hudson.model.Queue_-State>

          Daniel Beck added a comment -

          Hmmm… could this be related to JENKINS-34029?

          Daniel Beck added a comment - Hmmm… could this be related to JENKINS-34029 ?

          Cool, so that's actually a regression from beta2 where that information was saved. I think that's a completely separate defect since this jetty issue happened before then. Good find during TestFest!

          Kristin Whetstone added a comment - Cool, so that's actually a regression from beta2 where that information was saved. I think that's a completely separate defect since this jetty issue happened before then. Good find during TestFest!

          James Nord added a comment -

          Not saving the queue on windows was fixed recently on master.
          I'm unassigning from myself for the moment as I'm not looking at this. If I get to look at it and it's not taken I will re-assign it.

          James Nord added a comment - Not saving the queue on windows was fixed recently on master. I'm unassigning from myself for the moment as I'm not looking at this. If I get to look at it and it's not taken I will re-assign it.

          Sam Van Oort added a comment -

          Closing this since Kristin opened https://issues.jenkins-ci.org/browse/JENKINS-34281 which looks to be a completely separate issue.

          Sam Van Oort added a comment - Closing this since Kristin opened https://issues.jenkins-ci.org/browse/JENKINS-34281 which looks to be a completely separate issue.

          Sam Van Oort added a comment -

          Closing this, since Kristin has forked this out.

          Sam Van Oort added a comment - Closing this, since Kristin has forked this out.

            Unassigned Unassigned
            teilo James Nord
            Votes:
            0 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated:
              Resolved: