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

pidFile switch should prevent launching of multiple copies

    • Icon: New Feature New Feature
    • Resolution: Fixed
    • Icon: Major Major
    • swarm-plugin
    • None
    • Jenkins 2.90
      Swarm (plugin and jar): 3.6
    • 3.18

      It is currently not possible to prevent a second copy of the swarm client from being launched accidentally (through various automation errors, timing issues, etc).  I support a large swarm that handles cross-platform testing so I have automation on multiple linux and windows OS variants with different init systems.  Surprisingly, systemctl units are by far the worst offenders.

      Anyway, I feel that -pidFile switch is the place to create this type of locking.  Currently I can launch two clients and they will both run.  No combination of flags can prevent this.  For example:

      -name something  -master XXX -pidFile /tmp/jenkinspid -disableClientsUniqueId -deleteExistingClients

      This will cause the two copies to aggressively knock each other out every few seconds, forever, killing running jobs. Not a good option.

      -name something  -master XXX -pidFile /tmp/jenkinspid 

      This will cause the first copy to write a pidfile.  The second copy will delete the pidfile(!!) and then fail because that name (with or without -disableClientsUniqueId) is in use, so it will loop waiting to reconnect.   Terrible option.

       

      In my opinion, if -pidFile is specified, the second copy should not start (exit >0) when one is already running and matches the pid.  

          [JENKINS-48248] pidFile switch should prevent launching of multiple copies

          Alexander Komarov created issue -
          Alexander Komarov made changes -
          Description Original: It is currently not possible to prevent a second copy of the swarm client from being launched accidentally (through various automation errors, timing issues, etc).  I support a large swarm that handles cross-platform testing so I have automation on multiple linux and windows OS variants with different init systems.  Surprisingly, systemctl units are by far the worst offenders.

          Anyway, I feel that *-pidFile* switch is the place to create this type of locking.  Currently I can launch two clients and they will both run.  No combination of flags can prevent this.  For example:

          *-name something  -master XXX -pidFile /tmp/jenkinspid -disableClientsUniqueId -deleteExistingClients*

          This will cause the two copies to aggressively knock each other out every few seconds, forever, killing running jobs. Not a good option.

          *-name something  -master XXX -pidFile /tmp/jenkinspid* 

          This will cause the first copy to write a pidfile.  The second copy will *delete the pidfile(!!)* and then fail because that name (with or without -disableClientsUniqueId) is in use, so it will loop waiting to reconnect.   Terrible option.

           

          In my opinion, if -pidFile is specified, the second copy *should not start* when one is already running and matches the pid.  
          New: It is currently not possible to prevent a second copy of the swarm client from being launched accidentally (through various automation errors, timing issues, etc).  I support a large swarm that handles cross-platform testing so I have automation on multiple linux and windows OS variants with different init systems.  Surprisingly, systemctl units are by far the worst offenders.

          Anyway, I feel that *-pidFile* switch is the place to create this type of locking.  Currently I can launch two clients and they will both run.  No combination of flags can prevent this.  For example:

          *-name something  -master XXX -pidFile /tmp/jenkinspid -disableClientsUniqueId -deleteExistingClients*

          This will cause the two copies to aggressively knock each other out every few seconds, forever, killing running jobs. Not a good option.

          *-name something  -master XXX -pidFile /tmp/jenkinspid* 

          This will cause the first copy to write a pidfile.  The second copy will *delete the pidfile(!!)* and then fail because that name (with or without -disableClientsUniqueId) is in use, so it will loop waiting to reconnect.   Terrible option.

           

          In my opinion, if -pidFile is specified, the second copy *should not start* (exit >0) when one is already running and matches the pid.  
          Oleg Nenashev made changes -
          Assignee Original: Kohsuke Kawaguchi [ kohsuke ]
          Basil Crow made changes -
          Issue Type Original: Improvement [ 4 ] New: New Feature [ 2 ]
          Basil Crow made changes -
          Priority Original: Minor [ 4 ] New: Major [ 3 ]
          Basil Crow made changes -
          Released As New: 3.18
          Resolution New: Fixed [ 1 ]
          Status Original: Open [ 1 ] New: Fixed but Unreleased [ 10203 ]
          Basil Crow made changes -
          Assignee New: Alexander Komarov [ akom ]
          Status Original: Fixed but Unreleased [ 10203 ] New: Resolved [ 5 ]

            akom Alexander Komarov
            akom Alexander Komarov
            Votes:
            0 Vote for this issue
            Watchers:
            3 Start watching this issue

              Created:
              Updated:
              Resolved: