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

Perforce plugin hangs executor if username does not match email address

    Details

    • Type: Bug
    • Status: Closed (View Workflow)
    • Priority: Critical
    • Resolution: Fixed
    • Component/s: p4-plugin
    • Labels:
      None
    • Environment:
      Hudson 1.328
      Perforce plugin 1.0.16
      Extended Email (email-ext) plugin 2.2.1
      Perforce server 2007.2
    • Similar Issues:

      Description

      The new Perforce plugin can cause jobs to hang when trying to get the email address of a user whose Perforce username does not match the part of the email address before the @-sign. Given this user:

      $ p4 user -o bobby
      # A Perforce User Specification.
      #
      #  User:        The user's user name.
      #  Email:       The user's email address; for email review.
      #  Update:      The date this specification was last modified.
      #  Access:      The date this user was last active.  Read only.
      #  FullName:    The user's real name.
      #  JobView:     Selects jobs for inclusion during changelist creation.
      #  Password:    If set, user must have matching $P4PASSWD on client.
      #  Reviews:     Listing of depot files to be reviewed by user.
      
      User:   bobby
      
      Email:  bobsmith@example.com
      
      Update: 2009/10/27 13:23:04
      
      Access: 2010/01/27 09:36:35
      
      FullName:       Bobby Smith
      
      Password:       ******
      

      the following log entries and exception appear in the Tomcat logfiles:

      [install-server-main-L8-cluster-SPLUS-manager-2] $ p4 user -o bobby
      58973079 [Executor #1 for master : executing validate-server-main-L8-cluster-SPLUS #11] WARN perforce - Perforce process terminated suddenly
      58973080 [Executor #1 for master : executing validate-server-main-L8-cluster-SPLUS #11] WARN perforce - java.io.InterruptedIOException
              at java.io.PipedInputStream.read(Unknown Source)
              at java.io.PipedInputStream.read(Unknown Source)
              at sun.nio.cs.StreamDecoder.readBytes(Unknown Source)
              at sun.nio.cs.StreamDecoder.implRead(Unknown Source)
              at sun.nio.cs.StreamDecoder.read(Unknown Source)
              at java.io.InputStreamReader.read(Unknown Source)
              at java.io.BufferedReader.fill(Unknown Source)
              at java.io.BufferedReader.readLine(Unknown Source)
              at java.io.BufferedReader.readLine(Unknown Source)
              at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:278)
              at com.tek42.perforce.parse.Users.getUser(Users.java:52)
              at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:32)
              at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:86)
              at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:476)
              at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:303)
              at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:249)
              at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:241)
              at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:199)
              at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
              at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:501)
              at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:487)
              at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:475)
              at hudson.model.Build$RunnerImpl.cleanUp(Build.java:187)
              at hudson.model.Run.run(Run.java:1162)
              at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
              at hudson.model.ResourceController.execute(ResourceController.java:88)
              at hudson.model.Executor.run(Executor.java:123)
      
      Could not get email address from Perforce: No output for: p4 user -o bobby
      

      Meanwhile, the console log is stuck at:

      Started by upstream project "install-server-main-L8-cluster-SPLUS-worker-1" build number 13
      Building on master
      Using master perforce client: validate-server
      [workspace] $ p4 workspace -o validate-server
      Changing P4 Client Root to: /opt/hudson/hudson/jobs/validate-server-main-L8-cluster-SPLUS/workspace/
      Saving modified client validate-server
      [workspace] $ p4 -s client -i
      Last sync'd change: 306721
      [workspace] $ p4 counter change
      [workspace] $ p4 -s changes //validate-server/...@306722,@306741
      Sync'ing workspace to changelist 306741.
      [workspace] $ p4 sync //validate-server/...@306741
      Sync complete, took 99 ms
      [deploy] $ /opt/hudson/hudson/tools/ant/bin/ant -file validate.xml -Dservice.url=http://searil6406v:8080/SplusServer test-spserver-available
      Buildfile: validate.xml
      
      test-spserver-available:
      Build timed out. Aborting
      Email was triggered for: Failure
      There are 1 triggered emails.
      Sending email for trigger: Failure
      [spinner]
      

        Attachments

          Activity

          Hide
          bbassett Brian Bassett added a comment -

          Forgot to set component information

          Show
          bbassett Brian Bassett added a comment - Forgot to set component information
          Hide
          rpetti Rob Petti added a comment -

          Can you verify that it does NOT hang when the e-mail is set to bobby@example.com? The code does not extend any special treatment for email addresses; it's just another field in the perforce response.

          Also please ensure that all your perforce jobs are correctly configured, not just the one you are running.

          Show
          rpetti Rob Petti added a comment - Can you verify that it does NOT hang when the e-mail is set to bobby@example.com? The code does not extend any special treatment for email addresses; it's just another field in the perforce response. Also please ensure that all your perforce jobs are correctly configured, not just the one you are running.
          Hide
          bbassett Brian Bassett added a comment -

          I can verify it does not hang with other users who have matching usernames and email addresses. eg,

          $ p4 user -o bbassett
          ...
          Email: bbassett@example.com
          ...

          Neither users have configuration records in HUDSON_HOME/users/${USERNAME}/config.xml.

          All Perforce jobs appear to be configured correctly. They sync correctly from the depot when triggered; if there is a different definition to "correctly configured", I'd appreciate knowing

          I forgot to mention this in the original report, but this configuration worked with version 1.0.15 of the Perforce plugin. Updating to 1.0.16 caused the issue to appear.

          Our Perforce server is not named "perforce"; it is instead named "seaperforce.example.com", since the company I work for was acquired and the new company already had a "perforce.example.com". This issue regularly trips up our users, and might be a possible cause here.

          Show
          bbassett Brian Bassett added a comment - I can verify it does not hang with other users who have matching usernames and email addresses. eg, $ p4 user -o bbassett ... Email: bbassett@example.com ... Neither users have configuration records in HUDSON_HOME/users/${USERNAME}/config.xml. All Perforce jobs appear to be configured correctly. They sync correctly from the depot when triggered; if there is a different definition to "correctly configured", I'd appreciate knowing I forgot to mention this in the original report, but this configuration worked with version 1.0.15 of the Perforce plugin. Updating to 1.0.16 caused the issue to appear. Our Perforce server is not named "perforce"; it is instead named "seaperforce.example.com", since the company I work for was acquired and the new company already had a "perforce.example.com". This issue regularly trips up our users, and might be a possible cause here.
          Hide
          rpetti Rob Petti added a comment -

          As long as all the jobs can sync properly then that's fine. The MailAddressResolver classes cannot be tied to jobs, so it's forced to go through the perforce configurations one by one until it finds the user it's looking for (this includes disabled jobs as well, apparently). If a job isn't correctly configured, that could result in a hang (though really it should time out after a while).

          In any case, I can't reproduce this behavior at all using 1.0.16 on hudson 1.318, or 1.0.18 on hudson 1.339.

          It looks like the reason that it 'worked' in 1.0.15 is because the mail resolver was outright disabled. It looks like another user was running into the same issue, and just commented the entire thing out instead of trying to fix it.

          One thing that comes to mind is that while perforce commands are run on the slave during a build, mail resolution actually takes place on the master. If the perforce server is reachable from the slaves, but not the master, then that would produce exactly the behavior you are seeing.

          Show
          rpetti Rob Petti added a comment - As long as all the jobs can sync properly then that's fine. The MailAddressResolver classes cannot be tied to jobs, so it's forced to go through the perforce configurations one by one until it finds the user it's looking for (this includes disabled jobs as well, apparently). If a job isn't correctly configured, that could result in a hang (though really it should time out after a while). In any case, I can't reproduce this behavior at all using 1.0.16 on hudson 1.318, or 1.0.18 on hudson 1.339. It looks like the reason that it 'worked' in 1.0.15 is because the mail resolver was outright disabled. It looks like another user was running into the same issue, and just commented the entire thing out instead of trying to fix it. One thing that comes to mind is that while perforce commands are run on the slave during a build, mail resolution actually takes place on the master. If the perforce server is reachable from the slaves, but not the master, then that would produce exactly the behavior you are seeing.
          Hide
          aflat aflat added a comment -

          I'm having the exact same issue, it doesn't appear to timeout either, I let it go about 16 hours, and it was still hung. You also can't kill the job, I have to restart the Hudson master. A bit more info

          Hudson 1.345 and 1.343
          Perforce plugin 1.0.18
          Perforce 2009.1(the api did change with 2009.1 so this may be something to look at)

          It does work for users where the username and email match, but if any of the submitters don't match it hangs.

          Show
          aflat aflat added a comment - I'm having the exact same issue, it doesn't appear to timeout either, I let it go about 16 hours, and it was still hung. You also can't kill the job, I have to restart the Hudson master. A bit more info Hudson 1.345 and 1.343 Perforce plugin 1.0.18 Perforce 2009.1(the api did change with 2009.1 so this may be something to look at) It does work for users where the username and email match, but if any of the submitters don't match it hangs.
          Hide
          aflat aflat added a comment - - edited

          A bit more info. I'm running the hudson master on a windows box, as a service, using the localsystem account. Even though I create a p4ticket file(as a daemon user), it looks like the perforce plugin is having a hard time accessing it. I was playing with the tek42 api's and I couldn't access my server using my daemon p4 account. Once I switched to my local account, then I could switch back to the daemon account, and everything was fine. So

          try {
                             Depot depot = new Depot();
                              depot.setUser("daemonuser");
                 
                              depot.setPassword("daemonuserspassword");
          
                              depot.setPort("perforce:1666");
                              System.out.println("de: "+ depot.info());
                              com.tek42.perforce.model.User pu =depot.getUsers().getUser("ARealUser");
          
                              if (pu.getEmail() != null && !pu.getEmail().equals(""))
                                  System.out.println("em" + pu.getEmail());
          
                          } catch (Exception e) {
                              System.out.println("Could not get email address from Perforce: "+e.getMessage());
                          }
          

          This failed, the p4 info worked, but I couldn't get the email. Once I changed the depot.setusername to ARealUser, then I could get the email. Changing the depot.setusername back to daemonuser worked after that. Logging into p4v doesn't seem to fix anything.

          So for valid testing it looks like you need to remove your ticket file.

          Show
          aflat aflat added a comment - - edited A bit more info. I'm running the hudson master on a windows box, as a service, using the localsystem account. Even though I create a p4ticket file(as a daemon user), it looks like the perforce plugin is having a hard time accessing it. I was playing with the tek42 api's and I couldn't access my server using my daemon p4 account. Once I switched to my local account, then I could switch back to the daemon account, and everything was fine. So try { Depot depot = new Depot(); depot.setUser( "daemonuser" ); depot.setPassword( "daemonuserspassword" ); depot.setPort( "perforce:1666" ); System .out.println( "de: " + depot.info()); com.tek42.perforce.model.User pu =depot.getUsers().getUser( "ARealUser" ); if (pu.getEmail() != null && !pu.getEmail().equals("")) System .out.println( "em" + pu.getEmail()); } catch (Exception e) { System .out.println( "Could not get email address from Perforce: " +e.getMessage()); } This failed, the p4 info worked, but I couldn't get the email. Once I changed the depot.setusername to ARealUser, then I could get the email. Changing the depot.setusername back to daemonuser worked after that. Logging into p4v doesn't seem to fix anything. So for valid testing it looks like you need to remove your ticket file.
          Hide
          rpetti Rob Petti added a comment -

          bbassett: are you also running hudson on a windows server? Is it running as a service?

          As a quick note, p4 info doesn't require a valid login (or even a username for that matter) in order to run, so it may not be the best test.

          Tested with:
          Hudson 1.345
          Perforce Plugin 1.0.18
          email-ext 2.5
          p4 client 2009.1
          p4d server 2009.2
          Perforce security level 3

          Removing the tickets file doesn't reproduce the problem on my end.

          I've made some changes to the perforce email resolver that will make it a bit more robust. They'll be in 1.0.19, so please test again using that release.

          Show
          rpetti Rob Petti added a comment - bbassett: are you also running hudson on a windows server? Is it running as a service? As a quick note, p4 info doesn't require a valid login (or even a username for that matter) in order to run, so it may not be the best test. Tested with: Hudson 1.345 Perforce Plugin 1.0.18 email-ext 2.5 p4 client 2009.1 p4d server 2009.2 Perforce security level 3 Removing the tickets file doesn't reproduce the problem on my end. I've made some changes to the perforce email resolver that will make it a bit more robust. They'll be in 1.0.19, so please test again using that release.
          Hide
          bbassett Brian Bassett added a comment -

          No. We are running on a Linux master with both Linux and Windows slaves experiencing the issue.

          Show
          bbassett Brian Bassett added a comment - No. We are running on a Linux master with both Linux and Windows slaves experiencing the issue.
          Hide
          rpetti Rob Petti added a comment -

          Ok. In any case, give 1.0.19 a shot and let me know if anything changes.

          Show
          rpetti Rob Petti added a comment - Ok. In any case, give 1.0.19 a shot and let me know if anything changes.
          Hide
          aflat aflat added a comment -

          Preliminary tests on 1.0.19 seems much better, it's not hanging, and finding the right email addresses, thank you so much! I only ran a few tests, so we'll see on monday once I start getting lots of users submitting.

          Show
          aflat aflat added a comment - Preliminary tests on 1.0.19 seems much better, it's not hanging, and finding the right email addresses, thank you so much! I only ran a few tests, so we'll see on monday once I start getting lots of users submitting.
          Hide
          rpetti Rob Petti added a comment -

          Awesome! That's good to hear, because I was running out of ideas fast. I'll leave the bug open for a while in case something else comes up.

          Show
          rpetti Rob Petti added a comment - Awesome! That's good to hear, because I was running out of ideas fast. I'll leave the bug open for a while in case something else comes up.
          Hide
          aflat aflat added a comment -

          Spoke too soon I guess. I had to grab 1.0.20 to fix the SCM polling issue, and part of it is still fixed. I had a a few changes in a build, one by a daemon user, "build", with an email of releaseengineers@company.com, which did evaluate fine, but oddly enough real users don't resolve correctly. My usernames are <first initial><lastname> and their emails are <firstname>.<lastname>@company.com but the perforce plugin is resolving them to <first initial><lastname>@companyname.com so it's just using the username.

          This only appears to be the case on linux slaves, windows slaves it behaves just fine, (both connected to a windows master) which makes me think it's a case sensitivity issue.

          Show
          aflat aflat added a comment - Spoke too soon I guess. I had to grab 1.0.20 to fix the SCM polling issue, and part of it is still fixed. I had a a few changes in a build, one by a daemon user, "build", with an email of releaseengineers@company.com, which did evaluate fine, but oddly enough real users don't resolve correctly. My usernames are <first initial><lastname> and their emails are <firstname>.<lastname>@company.com but the perforce plugin is resolving them to <first initial><lastname>@companyname.com so it's just using the username. This only appears to be the case on linux slaves, windows slaves it behaves just fine, (both connected to a windows master) which makes me think it's a case sensitivity issue.
          Hide
          rpetti Rob Petti added a comment -

          That's really bizarre that it doesn't work on linux slaves... The perforce mail resolver has no idea what job it's even resolving for, let alone what slave it's running on. Email resolution takes place globally. With that in mind, it's possible hudson can return the email address as it's defined in another SCM entirely. As long as the username has made commits to the SCM as defined by any job, it should try and grab the email from it. Then it will just return whichever one it finds first.

          The only thing I can think of is that hudson is just grabbing the last resolved email from the previous builds for those jobs that are running on the linux slaves, which may have been the default "username@defaultdomain" construct. During testing, I've had to delete all previous builds for the test job (HUDSON_HOME/jobs/JOBNAME/builds/*) as well as any users that may have been accidentally defined (HUDSON_HOME/users). Otherwise, the perforce plugin doesn't even get a shot at getting the email address.

          Show
          rpetti Rob Petti added a comment - That's really bizarre that it doesn't work on linux slaves... The perforce mail resolver has no idea what job it's even resolving for, let alone what slave it's running on. Email resolution takes place globally. With that in mind, it's possible hudson can return the email address as it's defined in another SCM entirely. As long as the username has made commits to the SCM as defined by any job, it should try and grab the email from it. Then it will just return whichever one it finds first. The only thing I can think of is that hudson is just grabbing the last resolved email from the previous builds for those jobs that are running on the linux slaves, which may have been the default "username@defaultdomain" construct. During testing, I've had to delete all previous builds for the test job (HUDSON_HOME/jobs/JOBNAME/builds/*) as well as any users that may have been accidentally defined (HUDSON_HOME/users). Otherwise, the perforce plugin doesn't even get a shot at getting the email address.
          Hide
          aflat aflat added a comment -

          I created a new job on a new linux slave, and it doesn't resolve correctly. Use the same job, change it to a windows slave, it resolves correctly. Change it back to linux slave, and it fails to resolve again.

          Then I created a new job, new windows slave, new linux slave, ran it on windows first, email resolves correctly, change the job to linux, and it fails.

          Show
          aflat aflat added a comment - I created a new job on a new linux slave, and it doesn't resolve correctly. Use the same job, change it to a windows slave, it resolves correctly. Change it back to linux slave, and it fails to resolve again. Then I created a new job, new windows slave, new linux slave, ran it on windows first, email resolves correctly, change the job to linux, and it fails.
          Hide
          rpetti Rob Petti added a comment -

          Do you have any log output for those failures?

          Show
          rpetti Rob Petti added a comment - Do you have any log output for those failures?
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : kohsuke
          Path:
          trunk/hudson/main/core/src/main/java/hudson/tasks/MailAddressResolver.java
          http://jenkins-ci.org/commit/27623
          Log:
          JENKINS-5403 adding more logging in MailAddressResolver to help us figure out what's going on.

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : kohsuke Path: trunk/hudson/main/core/src/main/java/hudson/tasks/MailAddressResolver.java http://jenkins-ci.org/commit/27623 Log: JENKINS-5403 adding more logging in MailAddressResolver to help us figure out what's going on.
          Hide
          aflat aflat added a comment - - edited

          I guess I should have looked at the log earlier, I was only looking at the error log, but this was in the hudson.out.log

          [hudson] $ /usr/local/bin/p4 user -o perforce
          Could not get email address from Perforce: Could not run perforce command.

          Not sure why it doesn't work, that is the path to p4, but at least I have something to go on now.

          Show
          aflat aflat added a comment - - edited I guess I should have looked at the log earlier, I was only looking at the error log, but this was in the hudson.out.log [hudson] $ /usr/local/bin/p4 user -o perforce Could not get email address from Perforce: Could not run perforce command. Not sure why it doesn't work, that is the path to p4, but at least I have something to go on now.
          Hide
          rpetti Rob Petti added a comment -

          There's supposed to be a stack trace accompanying that message. I'll look into why it's not printing.

          Show
          rpetti Rob Petti added a comment - There's supposed to be a stack trace accompanying that message. I'll look into why it's not printing.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
          http://jenkins-ci.org/commit/27659
          Log:
          JENKINS-5403 adding additional logging (printStackTrace) for perforcemailresolver

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/27659 Log: JENKINS-5403 adding additional logging (printStackTrace) for perforcemailresolver
          Hide
          rpetti Rob Petti added a comment -

          I've attached a svn snapshot build of the previous commit, so we should be able to see why it can't run the perforce command.

          Show
          rpetti Rob Petti added a comment - I've attached a svn snapshot build of the previous commit, so we should be able to see why it can't run the perforce command.
          Hide
          aflat aflat added a comment - - edited

          I can build it locally as well, which is what I did, ignore the ": not set", that was me adding some debugging, I'm new to plugin development.

          Could not get email address from Perforce: Could not run perforce command.
          com.tek42.perforce.PerforceException: Could not run perforce command.: not set
          	at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:85)
          	at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:284)
          	at com.tek42.perforce.parse.Users.getUser(Users.java:52)
          	at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:53)
          	at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:81)
          	at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:476)
          	at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:293)
          	at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:227)
          	at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:219)
          	at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:180)
          	at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36)
          	at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582)
          	at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563)
          	at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550)
          	at hudson.model.Build$RunnerImpl.cleanUp(Build.java:158)
          	at hudson.model.Run.run(Run.java:1240)
          	at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
          	at hudson.model.ResourceController.execute(ResourceController.java:88)
          	at hudson.model.Executor.run(Executor.java:122)
          Caused by: java.io.IOException: Cannot run program "/usr/local/bin/p4" (in directory "\usr\local\hudson"): CreateProcess error=3, The system cannot find the path specified
          	at java.lang.ProcessBuilder.start(Unknown Source)
          	at hudson.Proc$LocalProc.<init>(Proc.java:149)
          	at hudson.Proc$LocalProc.<init>(Proc.java:121)
          	at hudson.Launcher$LocalLauncher.launch(Launcher.java:633)
          	at hudson.Launcher$ProcStarter.start(Launcher.java:268)
          	at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:75)
          	... 18 more
          Caused by: java.io.IOException: CreateProcess error=3, The system cannot find the path specified
          	at java.lang.ProcessImpl.create(Native Method)
          	at java.lang.ProcessImpl.<init>(Unknown Source)
          	at java.lang.ProcessImpl.start(Unknown Source)
          
          Show
          aflat aflat added a comment - - edited I can build it locally as well, which is what I did, ignore the ": not set", that was me adding some debugging, I'm new to plugin development. Could not get email address from Perforce: Could not run perforce command. com.tek42.perforce.PerforceException: Could not run perforce command.: not set at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:85) at com.tek42.perforce.parse.AbstractPerforceTemplate.getPerforceResponse(AbstractPerforceTemplate.java:284) at com.tek42.perforce.parse.Users.getUser(Users.java:52) at hudson.plugins.perforce.PerforceMailResolver.findMailAddressFor(PerforceMailResolver.java:53) at hudson.tasks.MailAddressResolver.resolve(MailAddressResolver.java:81) at hudson.tasks.Mailer$UserProperty.getAddress(Mailer.java:476) at hudson.plugins.emailext.ExtendedEmailPublisher.createMail(ExtendedEmailPublisher.java:293) at hudson.plugins.emailext.ExtendedEmailPublisher.sendMail(ExtendedEmailPublisher.java:227) at hudson.plugins.emailext.ExtendedEmailPublisher._perform(ExtendedEmailPublisher.java:219) at hudson.plugins.emailext.ExtendedEmailPublisher.perform(ExtendedEmailPublisher.java:180) at hudson.tasks.BuildStepMonitor$3.perform(BuildStepMonitor.java:36) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:582) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:563) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildStep(AbstractBuild.java:550) at hudson.model.Build$RunnerImpl.cleanUp(Build.java:158) at hudson.model.Run.run(Run.java:1240) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:122) Caused by: java.io.IOException: Cannot run program "/usr/local/bin/p4" (in directory "\usr\local\hudson" ): CreateProcess error=3, The system cannot find the path specified at java.lang.ProcessBuilder.start(Unknown Source) at hudson.Proc$LocalProc.<init>(Proc.java:149) at hudson.Proc$LocalProc.<init>(Proc.java:121) at hudson.Launcher$LocalLauncher.launch(Launcher.java:633) at hudson.Launcher$ProcStarter.start(Launcher.java:268) at hudson.plugins.perforce.HudsonP4Executor.exec(HudsonP4Executor.java:75) ... 18 more Caused by: java.io.IOException: CreateProcess error=3, The system cannot find the path specified at java.lang.ProcessImpl.create(Native Method) at java.lang.ProcessImpl.<init>(Unknown Source) at java.lang.ProcessImpl.start(Unknown Source)
          Hide
          aflat aflat added a comment -

          I should note that the sync works, so the path is correct, it's only on the email resolve. At least I think that makes sense.

          Show
          aflat aflat added a comment - I should note that the sync works, so the path is correct, it's only on the email resolve. At least I think that makes sense.
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
          http://jenkins-ci.org/commit/27660
          Log:
          JENKINS-5403 simplifying workspace retreival for PerforceMailResolver

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/27660 Log: JENKINS-5403 simplifying workspace retreival for PerforceMailResolver
          Hide
          rpetti Rob Petti added a comment -

          Can you rebuild from latest and try again, please?

          Show
          rpetti Rob Petti added a comment - Can you rebuild from latest and try again, please?
          Hide
          aflat aflat added a comment -

          Same error, same stack trace

          Show
          aflat aflat added a comment - Same error, same stack trace
          Hide
          rpetti Rob Petti added a comment - - edited

          Ok, I was able to reproduce the problem by specifying an invalid root directory for the linux node. I used backslashes instead of slashes, and while that allows the sync to work properly (not sure how yet), the email resolution still fails.

          This line

          Caused by: java.io.IOException: Cannot run program "/usr/local/bin/p4" (in directory "\usr\local\hudson"): CreateProcess error=3, The system cannot find the path specified
          

          Suggests that you have "\usr\local\hudson" set as the node's root instead of /usr/local/hudson. Is this the case?

          Show
          rpetti Rob Petti added a comment - - edited Ok, I was able to reproduce the problem by specifying an invalid root directory for the linux node. I used backslashes instead of slashes, and while that allows the sync to work properly (not sure how yet), the email resolution still fails. This line Caused by: java.io.IOException: Cannot run program "/usr/local/bin/p4" (in directory "\usr\local\hudson" ): CreateProcess error=3, The system cannot find the path specified Suggests that you have "\usr\local\hudson" set as the node's root instead of /usr/local/hudson. Is this the case?
          Hide
          aflat aflat added a comment -

          Nope, I double checked, /usr/local/hudson is the path in hudson(I even checked the config.xml to make sure it wasn't a display thing)

          Show
          aflat aflat added a comment - Nope, I double checked, /usr/local/hudson is the path in hudson(I even checked the config.xml to make sure it wasn't a display thing)
          Hide
          scm_issue_link SCM/JIRA link daemon added a comment -

          Code changed in hudson
          User: : rpetti
          Path:
          trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java
          http://jenkins-ci.org/commit/27661
          Log:
          JENKINS-5403 change the ad-hoc launcher in PerforceMailResolver to one created by the node instead of the master

          Show
          scm_issue_link SCM/JIRA link daemon added a comment - Code changed in hudson User: : rpetti Path: trunk/hudson/plugins/perforce/src/main/java/hudson/plugins/perforce/PerforceMailResolver.java http://jenkins-ci.org/commit/27661 Log: JENKINS-5403 change the ad-hoc launcher in PerforceMailResolver to one created by the node instead of the master
          Hide
          rpetti Rob Petti added a comment -

          One more time? After this I'll be completely out of ideas.

          Show
          rpetti Rob Petti added a comment - One more time? After this I'll be completely out of ideas.
          Hide
          aflat aflat added a comment -

          That did it, works great now, thank you so much!

          Show
          aflat aflat added a comment - That did it, works great now, thank you so much!
          Hide
          rpetti Rob Petti added a comment -

          Awesome!

          Fixed in subversion, will be in the 1.0.21 release.

          Show
          rpetti Rob Petti added a comment - Awesome! Fixed in subversion, will be in the 1.0.21 release.

            People

            • Assignee:
              rpetti Rob Petti
              Reporter:
              bbassett Brian Bassett
            • Votes:
              1 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: