• Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Minor Minor
    • None
    • Jenkins ver. 2.107.1

      The command launcher is difficult to use for powering on and off instances as they are needed.

      As can be seen in https://groups.google.com/forum/?nomobile=true#!topic/jenkinsci-users/EckKCU1rg9o users might want to have a script which: powers on a remote computer,  starts the remote agent, power off the remote computer. This can be useful when the instance is in the cloud, used rarely, and it's very expensive to keep it on.

      Currently the powering off is very difficult to do because the command-launcher-plugin kills the process (when running the remote agent), so the "power-off" command is not executed.

      Maybe you can use TERM instead of KILL to stop the process, in which case the script can handle the event. Best would be if the script is not killed at all, and instead leave the remote agent and the script to stop by themselves. Then it would be possible to run the remaining commands in the script, as expected. This would also eliminate the need to detail this termination behaviour in the plugin documentation.

          [JENKINS-50842] command-launcher terminates the process

          Alexandru Băluț created issue -
          Alexandru Băluț made changes -
          Description Original: The command launcher is difficult to use for powering on and off instances as they are needed.

          As can be seen in [https://groups.google.com/forum/?nomobile=true#!topic/jenkinsci-users/EckKCU1rg9o] users might want to have a script which: powers on a remote computer,  starts the remote agent, power off the remote computer. This can be useful when the instance is in the cloud, used rarely, and it's very expensive to keep it on.

          Currently the powering off is very difficult to do because the command-launcher-plugin terminates the process (when running the remote agent), so the "power-off" command is not executed.

          Maybe you can use KILL instead of TERM to stop the process, in which case the users could use "trap power-off-method EXIT" to be able to power off the machine when the script is killed.
          New: The command launcher is difficult to use for powering on and off instances as they are needed.

          As can be seen in [https://groups.google.com/forum/?nomobile=true#!topic/jenkinsci-users/EckKCU1rg9o] users might want to have a script which: powers on a remote computer,  starts the remote agent, power off the remote computer. This can be useful when the instance is in the cloud, used rarely, and it's very expensive to keep it on.

          Currently the powering off is very difficult to do because the command-launcher-plugin terminates the process (when running the remote agent), so the "power-off" command is not executed.

          Maybe you can use KILL instead of TERM to stop the process, in which case the users could use "trap power-off-method EXIT" to be able to power off the machine when the script is killed. Best would be if the script is not killed at all, and instead leave the remote agent to stop by itself. Then it would be possible to run the remaining commands in the script as expected. This would also eliminate the need to detail this behaviour in the plugin documentation.

          Oleg Nenashev added a comment -

          For me it looks like a feature request, not as a defect.

          It could be preferable to use Cloud API for such operations. There is https://wiki.jenkins.io/display/JENKINS/Scripted+Cloud+plugin, but I am not sure it supports such use-case (and the plugin is outdated for sure)

          Oleg Nenashev added a comment - For me it looks like a feature request, not as a defect. It could be preferable to use Cloud API for such operations. There is https://wiki.jenkins.io/display/JENKINS/Scripted+Cloud+plugin , but I am not sure it supports such use-case (and the plugin is outdated for sure)
          Alexandru Băluț made changes -
          Description Original: The command launcher is difficult to use for powering on and off instances as they are needed.

          As can be seen in [https://groups.google.com/forum/?nomobile=true#!topic/jenkinsci-users/EckKCU1rg9o] users might want to have a script which: powers on a remote computer,  starts the remote agent, power off the remote computer. This can be useful when the instance is in the cloud, used rarely, and it's very expensive to keep it on.

          Currently the powering off is very difficult to do because the command-launcher-plugin terminates the process (when running the remote agent), so the "power-off" command is not executed.

          Maybe you can use KILL instead of TERM to stop the process, in which case the users could use "trap power-off-method EXIT" to be able to power off the machine when the script is killed. Best would be if the script is not killed at all, and instead leave the remote agent to stop by itself. Then it would be possible to run the remaining commands in the script as expected. This would also eliminate the need to detail this behaviour in the plugin documentation.
          New: The command launcher is difficult to use for powering on and off instances as they are needed.

          As can be seen in [https://groups.google.com/forum/?nomobile=true#!topic/jenkinsci-users/EckKCU1rg9o] users might want to have a script which: powers on a remote computer,  starts the remote agent, power off the remote computer. This can be useful when the instance is in the cloud, used rarely, and it's very expensive to keep it on.

          Currently the powering off is very difficult to do because the command-launcher-plugin kills the process (when running the remote agent), so the "power-off" command is not executed.

          Maybe you can use TERM instead of KILL to stop the process, in which case the script can handle the event. Best would be if the script is not killed at all, and instead leave the remote agent and the script to stop by themselves. Then it would be possible to run the remaining commands in the script, as expected. This would also eliminate the need to detail this termination behaviour in the plugin documentation.

          Alexandru Băluț added a comment - - edited

          Currently, the script is not allowed to finish, cannot handle the TERM event, cannot start a watchdog as its child processes are also killed.

          If the killing of the script (and all its child processes) is intentional, then the script must be allowed somehow to clean up after itself. How can we change Jenkins to allow this?

          Alexandru Băluț added a comment - - edited Currently, the script is not allowed to finish, cannot handle the TERM event, cannot start a watchdog as its child processes are also killed. If the killing of the script (and all its child processes) is intentional, then the script must be allowed somehow to clean up after itself. How can we change Jenkins to allow this?

          Artur Szostak added a comment -

          As a workaround you can spawn your own watchdog daemon that will not be killed when Jenkins foolishly puts a bullet in your process. You have to make sure the watchdog daemon is not part of the same process group, detach from stdin/stdout etc. Be warned, it will take an annoying period of time to debug this approach and get all the failure modes handled properly. But I have managed to implement this and make it work a while back.

          Artur Szostak added a comment - As a workaround you can spawn your own watchdog daemon that will not be killed when Jenkins foolishly puts a bullet in your process. You have to make sure the watchdog daemon is not part of the same process group, detach from stdin/stdout etc. Be warned, it will take an annoying period of time to debug this approach and get all the failure modes handled properly. But I have managed to implement this and make it work a while back.
          Jesse Glick made changes -
          Assignee Original: Jesse Glick [ jglick ]
          Jesse Glick made changes -
          Link New: This issue relates to JENKINS-5399 [ JENKINS-5399 ]

            Unassigned Unassigned
            aleb Alexandru Băluț
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated: