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

Init script fails to create ~/.hudson-run-init on completion and runs multiple times

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Minor
    • Resolution: Fixed
    • ec2-plugin
    • None
    • Jenkins 1.625.3
      Amazon EC2 plugin 1.31
      Master and slaves running Ubuntu 14.04

    Description

      I noticed my Unix slaves on EC2 do not have a ~/.hudson-run-init file, despite running the init script (and following setup steps) successfully. As a result, when they're brought back up from a stopped state, they run the init script again, wasting ~20 minutes.

      Some relevant AMI configuration:

      • Remote FS root: /home/ubuntu
      • Remote user: ubuntu
      • AMI Type: unix
      • Root command prefix: sudo
      • Init script is essentially: sudo $HOME/init_script.sh

      On a successfully connected slave, I expect to see /home/ubuntu/.hudson-run-init, but there's no such file. I took a quick look at EC2UnixLauncher.java, and everything looks reasonable. My only question is why touch ~/.hudson-run-init would need to be run as root. But both touch ~/.hudson-run-init and sudo touch ~/.hudson-run-init produce the expected file when run manually as the ubuntu user. So I'm a bit stumped.

      I'm testing out touching the file myself in the init script as a workaround.

      Attachments

        Activity

          PR has been merged if this is still an issue please reopen this with a new version of the plugin

          raihaan Raihaan Shouhell added a comment - PR has been merged if this is still an issue please reopen this with a new version of the plugin
          perrin Perrin Morrow added a comment -

          Well "more testing next week" turned into two years, sorry about that.

          I've pushed the code we've been running with for those two years in this pull request.

           

          perrin Perrin Morrow added a comment - Well "more testing next week" turned into two years, sorry about that. I've pushed the code we've been running with for those two years in  this pull request .  
          perrin Perrin Morrow added a comment -

          We've been seeing this behaviour too, but not consistently. Some of the time the file is created, and I can't see any obvious pattern.

          I am currently running a patched version of the plugin in our staging environment, with extra logging around the creation of the file to see why it might be failing. But so far it has created the file every time.

          It's possible my call to

          waitCompletion(sess);
          

          which I added to get the exit status may have caused it to work more reliably.

          I'll do some more testing next week.

          perrin Perrin Morrow added a comment - We've been seeing this behaviour too, but not consistently. Some of the time the file is created, and I can't see any obvious pattern. I am currently running a patched version of the plugin in our staging environment, with extra logging around the creation of the file to see why it might be failing. But so far it has created the file every time. It's possible my call to waitCompletion(sess); which I added to get the exit status may have caused it to work more reliably. I'll do some more testing next week.

          People

            francisu Francis Upton
            mihelich Patrick Mihelich
            Votes:
            0 Vote for this issue
            Watchers:
            4 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: