Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-16889

No cleanup SSH connections when slave action occurs

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Fixed
    • Labels:
      None
    • Environment:
      Debian 6.0.6 x86_64, Jenkins ver. 1.502, Jenkins Libvirt Slaves plugin 1.7
    • Similar Issues:

      Description

      I noticed some days ago that connections to libvirt from java binding
      with SSH URL leaves an SSH shell opened even after a
      connection is closed.

      The version of libvirt-java could be the problem. I think they fixed this behavour after the 0.4.2 version (src: http://libvirt.org/git/?p=libvirt-java.git;a=shortlog).

      Thank you in advance.

      Regards,

        Attachments

          Activity

          Hide
          tastybug Philipp Bartsch added a comment -

          Resolved in 1.8

          Show
          tastybug Philipp Bartsch added a comment - Resolved in 1.8
          Hide
          gkr G. Kr. added a comment -

          i had a look at the code and have a few questions:

          • shouldn't the connection be closed at some point? e.g. after it has not been in use for a few minutes/hours?
            probably latest when jenkins is shutdown? the Connect object has a finalize method that closes the connection but the Domain objects retrieved by the public getDomains() method contain a reference to that object, so it is not guaranteed that the garbage collector actually calls finalize(), is it?
          • in case of long running connections wouldn't it be necessary to check whether the Connect still isConnected()

          thanks

          Show
          gkr G. Kr. added a comment - i had a look at the code and have a few questions: shouldn't the connection be closed at some point? e.g. after it has not been in use for a few minutes/hours? probably latest when jenkins is shutdown? the Connect object has a finalize method that closes the connection but the Domain objects retrieved by the public getDomains() method contain a reference to that object, so it is not guaranteed that the garbage collector actually calls finalize(), is it? in case of long running connections wouldn't it be necessary to check whether the Connect still isConnected() thanks
          Hide
          tastybug Philipp Bartsch added a comment -

          1) The domain instances them self are not referenced by any other objects. When the gc collects those domain objects, the associated connection instance is going to be finalized as well and thus closed.
          Nonethelss I don't want to deal with manual disconnects right now as calling disconnect doesn't close the underlying SSH connection immediately. If I open and close too many connections within a short period of time, I once again might end up with 20 dead, not-yet-closed SSH connections which would prevent the creation of further sessions.
          For the moment I'll stick to one shared connection for the duration of the Jenkins lifecycle as that is simply the safest approach.

          2) Good point regarding the "stale" connections. Considering that libvirtd might crash or get restarted while Jenkins is running, I have to make sure that the connection is in fact working.

          I'm releasing a 1.8.1 to address this issue for the sake of reliability. Thanks for your input, much appreciated.

          Show
          tastybug Philipp Bartsch added a comment - 1) The domain instances them self are not referenced by any other objects. When the gc collects those domain objects, the associated connection instance is going to be finalized as well and thus closed. Nonethelss I don't want to deal with manual disconnects right now as calling disconnect doesn't close the underlying SSH connection immediately. If I open and close too many connections within a short period of time, I once again might end up with 20 dead, not-yet-closed SSH connections which would prevent the creation of further sessions. For the moment I'll stick to one shared connection for the duration of the Jenkins lifecycle as that is simply the safest approach. 2) Good point regarding the "stale" connections. Considering that libvirtd might crash or get restarted while Jenkins is running, I have to make sure that the connection is in fact working. I'm releasing a 1.8.1 to address this issue for the sake of reliability. Thanks for your input, much appreciated.
          Hide
          gkr G. Kr. added a comment -

          Thanks for clarification.

          I think having one shared connection is the best solution. Only the assumed "never closing" got me confused. That the SSH connection is not shutdown before close() returns sounds imho like a bug in upstream.

          Show
          gkr G. Kr. added a comment - Thanks for clarification. I think having one shared connection is the best solution. Only the assumed "never closing" got me confused. That the SSH connection is not shutdown before close() returns sounds imho like a bug in upstream.
          Hide
          gkr G. Kr. added a comment -

          closing as fixed

          Show
          gkr G. Kr. added a comment - closing as fixed

            People

            • Assignee:
              tastybug Philipp Bartsch
              Reporter:
              sox Florent Poinsaut
            • Votes:
              1 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: