Re: Send logs to syslog-ng or Splunk..
On Fri, 13 Jul 2012, Cowmix wrote: I know this has been asked a few times over the years (and at least one time by me on the Hudson users list) but is there a way to send a real-time copy of your raw build output to Splunk (or syslog-ng) for processing? I'm not sure anybody around here can afford Splunk to try out an integration ;) - R. Tyler Croy -- Code: http://github.com/rtyler Chatter: http://twitter.com/agentdero rty...@jabber.org signature.asc Description: Digital signature
Re: Jenkins Jobs Fail with Sonar Plugin enabled on Slave Nodes
have you tried to execute the same command on the command line?
- login to the slave (e.g. ssh) as the same user as the Jenkins slave is
running with
- change to the same directory
- execute the mvn command
some ideas:
- was the same workspace used by a different Jenkins before?
- did you change the user the slave is running with
/Domi
On 15.07.2012, at 03:46, krishna kurnala wrote:
Hello all
Has anyone faced the same issue before? Can you please guide me.
I am encountering below exception when I try to run a build on one of our
Jenkins Slaves, the same Job succeeds if i tie it to our Jenkins Master or
If I execute the Mvn sonar Command(in Bold below) from the cehcked-out
workspace on slave node or I add a goal mvn sonar:sonar along with mvn clean
deploy in my build steps.
[Services-Address] $ mvn -f
/home/jenkinspan/workspace/Services-Address/pom.xml -e -B sonar:sonar
-Dsonar.jdbc.driver=com.mysql.jdbc.Driver
-Dsonar.jdbc.url=jdbc:mysql://10.242.193.136:3306/sonar?useUnicode=truecharacterEncoding=utf8rewriteBatchedStatements=true
-Dsonar.host.url=http://10.242.195.243:9000/
FATAL: command execution failed
java.io.IOException: Cannot run program mvn (in directory
/home/jenkinspan/workspace/Services-Address): java.io.IOException:
error=13, Permission denied
at java.lang.ProcessBuilder.start(ProcessBuilder.java:475)
at hudson.Proc$LocalProc.init(Proc.java:244)
at hudson.Proc$LocalProc.init(Proc.java:216)
at hudson.Launcher$LocalLauncher.launch(Launcher.java:709)
at hudson.Launcher$ProcStarter.start(Launcher.java:338)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:934)
at hudson.Launcher$RemoteLaunchCallable.call(Launcher.java:901)
at hudson.remoting.UserRequest.perform(UserRequest.java:118)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:287)
at
hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
at java.util.concurrent.FutureTask.run(FutureTask.java:166)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603)
at java.lang.Thread.run(Thread.java:636)
Caused by: java.io.IOException: java.io.IOException: error=13, Permission
denied
at java.lang.UNIXProcess.init(UNIXProcess.java:164)
at java.lang.ProcessImpl.start(ProcessImpl.java:81)
at java.lang.ProcessBuilder.start(ProcessBuilder.java:468)
... 15 more
Sonar analysis completed: FAILURE
Build step 'Sonar' changed build result to FAILURE
Build step 'Sonar' marked build as failure
Email was triggered for: Failure
From the Look of it, I did verify that, the Maven PATH's are correct on both
Slave and Master.
I added the command echo $PATH before the build commences.
Master
echo
/usr/local/apache-ant-1.8.2/bin:/home/iorlov/jdk1.6.0_25/bin:/home/iorlov/perl5/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/iorlov/perl5/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/iorlov/bin:/home/iorlov/apache-maven-3.0.4/bin
Slave
[Services-Client-Sonar] $ /bin/sh -xe /tmp/hudson3958915402151014871.sh
+ echo
/home/jenkinspan/apache-ant-1.8.3/bin:/home/jenkinspan/jdk1.6.0_25/bin:/home/jenkinspan/apache-tomcat-7.0.28/bin:/home/jenkinspan/apache-maven-3.0.4/bin:/home/jenkinspan/apache-ant-1.8.3/bin:/home/jenkinspan/git-1.7.9.6:/usr/local/apache-ant-1.8.2/bin:/home/iorlov/jdk1.6.0_25/bin:/home/iorlov/perl5/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/iorlov/perl5/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/export/home/jenkinspan/bin:/home/jenkinspan/perl5/bin:/home/jenkinspan/apache-tomcat-7.0.28/bin:/home/jenkinspan/apache-maven-3.0.4/bin:/home/jenkinspan/apache-ant-1.8.3/bin:/home/jenkinspan/git-1.7.9.6:/usr/local/apache-ant-1.8.2/bin:/home/iorlov/jdk1.6.0_25/bin:/home/iorlov/perl5/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/home/iorlov/perl5/bin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin:/export/home/jenkinspan/bin:/home/jenkinspan/perl5/bin:/home/jenkinspan/apache-maven-3.0.4/bin:/export/home/jenkinspan/bin
Another hang while artifacting
Hi all, For a while we've seen occasional hangs during the artifact stage of some jobs. Of course they always seem to happen when we're under the gun and need a critical build, as was the case this morning ;-) Originally I thought that these hangs might be a disconnect between what the job is building and the list of artifacts. For example, I've definitely seen issues where if I change our build to create a new artifact, but there are jobs running that don't know how to produce the new artifact, the artifacting stage hangs. I've always theorized that in this case Jenkins searches our tree for the missing artifact, and is either bogged down by the shear size of our source tree (which is huge), or is confused by our use of symlinks in the tree. But to be honest, I've never tried to do more than guess at the problem. I *did* make a change like this a few days ago, and did see an artifacting hang. Since this was expected, I terminated that build. After that new jobs succeeded, until I got a hang out of the blue (with no build job changes) this morning. Here's the stack trace from the build slave that is hung: --snip-- Executor #1 for MacBuildSlave-Speedy : executing ClientMacFullInstaller #700 Id=58 Group=main TIMED_WAITING on [B@5c8c89e2 at java.lang.Object.wait(Native Method) - waiting on [B@5c8c89e2 at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:173) at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61) at java.util.zip.InflaterInputStream.fill(InflaterInputStream.java:221) at java.util.zip.InflaterInputStream.read(InflaterInputStream.java:141) at java.util.zip.GZIPInputStream.read(GZIPInputStream.java:90) at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257) at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223) at hudson.org.apache.tools.tar.TarInputStream.read(TarInputStream.java:345) at java.io.FilterInputStream.read(FilterInputStream.java:90) at org.apache.commons.io.IOUtils.copyLarge(IOUtils.java:1025) at org.apache.commons.io.IOUtils.copy(IOUtils.java:999) at hudson.util.IOUtils.copy(IOUtils.java:36) at hudson.FilePath.readFromTar(FilePath.java:1759) at hudson.FilePath.copyRecursiveTo(FilePath.java:1685) at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:116) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractRunner.perform(AbstractBuild.java:703) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:678) at hudson.model.AbstractBuild$AbstractRunner.performAllBuildSteps(AbstractBuild.java:656) at hudson.model.Build$RunnerImpl.post2(Build.java:162) at hudson.model.AbstractBuild$AbstractRunner.post(AbstractBuild.java:625) at hudson.model.Run.run(Run.java:1435) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:238) --snip-- Note that we're running Jenkins 1.455. I really want to get back to a state where we can trust that Jenkins will deliver builds without falling over. Is the above information helpful, or is more needed? Note that I've got a complete threadDump stack trace of all the slaves and threads in case that is helpful, but it seemed like way too much to post here. Is there anything else I can do to help diagnose this problem while it's happening? Unfortunately I cannot leave the build hung forever. I'll likely have to stop and restart it sometime today, so if anyone has suggestions as to what I can do next to look at the problem while it's still in front of me, please let me know soon. Best, -- Allen Cronce
Re: Incremental (character at a time) Console output
On 07/13/2012 06:44 PM, Sean DeNigris wrote: Does Jenkins wait for a newline to show new output in the console? Apparently it does. I filed JENKINS-14435 [1] to track this. I do not know of a workaround not involving a custom plugin, other than logging into master and using tail -f on the log file. [1] https://issues.jenkins-ci.org/browse/JENKINS-14435
Re: Incremental (character at a time) Console output
Jesse Glick-4 wrote I do not know of a workaround not involving a custom plugin Thanks for creating the issue. By a custom plugin, do you mean roll-my-own, or do you have one in mind? Sean -- View this message in context: http://jenkins.361315.n4.nabble.com/Incremental-character-at-a-time-Console-output-tp4634750p4634790.html Sent from the Jenkins users mailing list archive at Nabble.com.
Putting condition for build of same job
I have a project corresponding to a job.. I have do different kind of build job with same project.. Condition is like on set of build job is for doing after any commits to repository comes Another set of build job is to do build that schedule at night time. My question is How can i give build of same project due to commit as well as i want to schedule different build task for same job to nightly schedule? Thanks in Advance, varghese
