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

No cleanup SSH connections when slave action occurs

    XMLWordPrintable

Details

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

    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

          gkr G. Kr. added a comment -

          closing as fixed

          gkr G. Kr. added a comment - closing as fixed
          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.

          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.

          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.

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

          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

          Resolved in 1.8

          tastybug Philipp Bartsch added a comment - Resolved in 1.8

          People

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

            Dates

              Created:
              Updated:
              Resolved: