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

Doesn't shutdown emulator afted job is done

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Major
    • Resolution: Won't Fix
    • Labels:
      None
    • Environment:
      Arch linux with all latest updates. Jre7 etc...
    • Similar Issues:

      Description

      Sometimes emulator being closed, sometimes not. Spent all day trying to understand why this happens with no success. Wasn't able to find any similarities between runs.

        Attachments

          Activity

          audrius Audrius K created issue -
          Hide
          orrc Christopher Orr added a comment -

          This is a known issue; without any further details or a way to reproduce it, this can't be fixed in the plugin, in Jenkins or by the Android tool developers.

          https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin#AndroidEmulatorPlugin-AVDsmaynotshutdownfullyattheendofabuild

          One workaround is to periodically run a cronjob that forcibly kills any emulator processes which have been running for a certain period of time (in this case 10 minutes or longer):

          ps -U jenkins -o pid,etime,comm \
            | egrep ' emulator$' \
            | egrep -v ' 0[0-9]:[0-9]{2} ' \
            | awk '{print $1}' \
            | xargs kill -9 2> /dev/null
          
          Show
          orrc Christopher Orr added a comment - This is a known issue; without any further details or a way to reproduce it, this can't be fixed in the plugin, in Jenkins or by the Android tool developers. https://wiki.jenkins-ci.org/display/JENKINS/Android+Emulator+Plugin#AndroidEmulatorPlugin-AVDsmaynotshutdownfullyattheendofabuild One workaround is to periodically run a cronjob that forcibly kills any emulator processes which have been running for a certain period of time (in this case 10 minutes or longer): ps -U jenkins -o pid,etime,comm \ | egrep ' emulator$' \ | egrep -v ' 0[0-9]:[0-9]{2} ' \ | awk '{print $1}' \ | xargs kill -9 2> /dev/null
          orrc Christopher Orr made changes -
          Field Original Value New Value
          Status Open [ 1 ] Resolved [ 5 ]
          Resolution Won't Fix [ 2 ]
          Hide
          audrius Audrius K added a comment -

          Used this workaround for some time, but it isn't very flexible when working with different project. Some project can run tests longer then 10 min. Some fits in small time interval and emulator needs to be used faster then 10 min mark.

          Did anyone even tried to run Jenkins in any Linux dist with such config:
          *Android plugin
          *In one node at least 4 executors
          *Multi-configuration project with running instances parallelly.

          Noticed that there are less unclosed emulator instances when less emulators are running. Basically running 1 project with 1 emulator instance never seen unsuccessful closing.

          Show
          audrius Audrius K added a comment - Used this workaround for some time, but it isn't very flexible when working with different project. Some project can run tests longer then 10 min. Some fits in small time interval and emulator needs to be used faster then 10 min mark. Did anyone even tried to run Jenkins in any Linux dist with such config: *Android plugin *In one node at least 4 executors *Multi-configuration project with running instances parallelly. Noticed that there are less unclosed emulator instances when less emulators are running. Basically running 1 project with 1 emulator instance never seen unsuccessful closing.
          Hide
          orrc Christopher Orr added a comment -

          Yes, I use that configuration every day, with multiple nodes, each with four executors running in parallel.
          We also have some long-running jobs and, while the emulators don't always stop, I use the above "kill" workaround to stop emulators that have been running for longer than two hours (since we have some jobs that run for three minutes or so, and longer ones of 90+ minutes).

          I have also tested the plugin on a machine with at least 12 parallel builds (mentioned at the below link), and there were no issues with the emulators shutting down improperly.
          https://issues.jenkins-ci.org/browse/JENKINS-7354?focusedCommentId=142210&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-142210

          Show
          orrc Christopher Orr added a comment - Yes, I use that configuration every day, with multiple nodes, each with four executors running in parallel. We also have some long-running jobs and, while the emulators don't always stop, I use the above "kill" workaround to stop emulators that have been running for longer than two hours (since we have some jobs that run for three minutes or so, and longer ones of 90+ minutes). I have also tested the plugin on a machine with at least 12 parallel builds (mentioned at the below link), and there were no issues with the emulators shutting down improperly. https://issues.jenkins-ci.org/browse/JENKINS-7354?focusedCommentId=142210&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-142210
          Hide
          audrius Audrius K added a comment -

          I don't have time to try myself, but does this code works as it should?
          AndroidEmulator.java:525

          boolean killed = sendEmulatorCommand(launcher, logger, userPort, "kill");
          
          // Ensure the process is dead
          if (!killed && emulatorProcess.isAlive()) {
             emulatorProcess.kill();
          }
          

          In this situation emulator thinks that it will be closed properly so killed == true so emulatorProcess.kill(); is ignored...

          Show
          audrius Audrius K added a comment - I don't have time to try myself, but does this code works as it should? AndroidEmulator.java:525 boolean killed = sendEmulatorCommand(launcher, logger, userPort, "kill" ); // Ensure the process is dead if (!killed && emulatorProcess.isAlive()) { emulatorProcess.kill(); } In this situation emulator thinks that it will be closed properly so killed == true so emulatorProcess.kill(); is ignored...
          Hide
          orrc Christopher Orr added a comment -

          Originally, only the emulatorProcess.kill() command was used when trying to kill the emulator process.
          Because that didn't always work, the sendEmulatorCommand was used instead in an attempt to make shutdown more reliable.

          So I don't believe unconditionally calling kill() here would add anything.

          Show
          orrc Christopher Orr added a comment - Originally, only the emulatorProcess.kill() command was used when trying to kill the emulator process. Because that didn't always work, the sendEmulatorCommand was used instead in an attempt to make shutdown more reliable. So I don't believe unconditionally calling kill() here would add anything.
          Hide
          oldelvet Richard Mortimer added a comment -

          I have been seeing a similar issue with the emulator not shutting down properly. So far I have not isolated a specific test case that reliably reproduces the issue. I have however spotted a number of issues that may contribute to the problem. I will log these in separate JIRA to keep things simple.

          Show
          oldelvet Richard Mortimer added a comment - I have been seeing a similar issue with the emulator not shutting down properly. So far I have not isolated a specific test case that reliably reproduces the issue. I have however spotted a number of issues that may contribute to the problem. I will log these in separate JIRA to keep things simple.
          Hide
          orrc Christopher Orr added a comment -

          Marking old "resolved" issues as "closed".

          Show
          orrc Christopher Orr added a comment - Marking old "resolved" issues as "closed".
          orrc Christopher Orr made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          rtyler R. Tyler Croy made changes -
          Workflow JNJira [ 140833 ] JNJira + In-Review [ 205270 ]

            People

            • Assignee:
              orrc Christopher Orr
              Reporter:
              audrius Audrius K
            • Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: