[JIRA] [core] (JENKINS-23248) CLI: get-job calls are causing file descriptor leaks.
Damon G commented on JENKINS-23248 CLI: get-job calls are causing file descriptor leaks. Hi Daniel, so are you all set with help? Matt pinpointed the version of the remoting library. Looks like there was a pretty major refactoring done between 2.37 and 2.38. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [cli] (JENKINS-23248) CLI: get-job calls are causing file descriptor leaks.
Damon G commented on JENKINS-23248 CLI: get-job calls are causing file descriptor leaks. Hi Daniel, It may take me a few days to get back to you but yes i could run this test against the intermediary versions. I've cloned this vm off into an isolated environment for testing. Isn't there something else I could do at the same time to narrow it down? lsof just shows me that the file descriptors are leaking from java. Any sort of jenkins tracing I might want to enable at the same time that might narrow down where it's coming from? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [cli] (JENKINS-23248) CLI: get-job calls are causing file descriptor leaks.
Damon G edited a comment on JENKINS-23248 CLI: get-job calls are causing file descriptor leaks. Hi Daniel, It may take me a few days to get back to you but yes i could run this test against the intermediary versions. I've cloned this vm off into an isolated environment for testing. Isn't there something else I could do at the same time to narrow it down? lsof just shows me that the file descriptors are leaking from java. Any sort of jenkins tracing I might want to enable at the same time that might narrow down where it's coming from? Actually it looks like we'll be able to try this on Thursday. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [cli] (JENKINS-23572) Repeated calls to jenkins cli results in Too many open files exception on the master
Damon G updated JENKINS-23572 Repeated calls to jenkins cli results in Too many open files exception on the master Change By: Damon G (30/Jun/14 11:58 PM) Summary: Repeatedcallstojenkinscliresultsin Toomanyopenfilesexception onthemaster Priority: Major Critical Description: Wecanrunforabout2daysandthenthesystembasicallybecomesunresponsiveandneedstoberestarted.Everythingwasgoingfineformanymonthsatversion1.5.46butoncewewentto1.5.66or1.5.68webegintoseetoomanyopenfilesexceptionsuntiljenkinsneededarestart.Attachedarethestacktraces.IdidntchooseaspecificcomponentbecauseIwasntsurewhichcomponenttologitagainst.Ialsodontseeanyexistingopenissuesthatmatchthis.Hopeopeningthiswasvalid.Iveattachedalistofallfilesopened(usinglsof)byjenkinsaswellasthejenkinslogcontainingthestacktraces.IonlyincludedacoupleofthestacktracesbecauseIhaveafeelingtheoutputoflsofmaybemoreilluminating.Happytoprovideanythingmoreyouneed.ThisisoneofmyfirstdefectssoIhopeImgivingenoughdetailwithoutitalreadybeingaknownissue.Update-Wedidan experiement experiment wherewerepeatedlyranthejenkinscli withtheoptiontosetabuilddescription .Wedidthisbecauseourjenkinsjobsutilizeitheavilyandweweresuspiciousitmightberelated.Foreveryjenkinsclicommandexecutedgeneratedanotheropenfilereferencethatdoesntappeartogetclosed.Itcorrespondstoentriesinlsoflikethis:java1230jenkins3772usock0,70t053062cantidentifyprotocolItdoesntlooklikethisfilesareevergettingclosed.Ifyoulookinthatlsoffileyoullseeroughly11,000linesjustliketheoneabove. Component/s: cli Component/s: other This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [cli] (JENKINS-23248) CLI: get-job calls are causing file descriptor leaks.
Damon G commented on JENKINS-23248 CLI: get-job calls are causing file descriptor leaks. I just logged jenkins-23572 about a week ago and it looks like this exact same issue. Happy to mark my a duplicate of this or run tests to determine the root cause. We are calling the CLI from within our groovy test code inside of our job while it's executing on the slaves. I don't see how I could work around this by closing file descriptors in my wrapper code that's executing on the slave since it's on the master where there are too many open file descriptors. Maybe your job was executing directly on the master? This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [other] (JENKINS-23572) Too many open files exception
Damon G updated JENKINS-23572 Too many open files exception Change By: Damon G (26/Jun/14 11:46 AM) Description: Wecanrunforabout2daysandthenthesystembasicallybecomesunresponsiveandneedstoberestarted.Everythingwasgoingfineformanymonthsatversion1.5.46butoncewewentto1.5.66or1.5.68webegintoseetoomanyopenfilesexceptionsuntiljenkinsneededarestart.Attachedarethestacktraces.IdidntchooseaspecificcomponentbecauseIwasntsurewhichcomponenttologitagainst.Ialsodontseeanyexistingopenissuesthatmatchthis.Hopeopeningthiswasvalid.Iveattachedalistofallfilesopened(usinglsof)byjenkinsaswellasthejenkinslogcontainingthestacktraces.IonlyincludedacoupleofthestacktracesbecauseIhaveafeelingtheoutputoflsofmaybemoreilluminating.Happytoprovideanythingmoreyouneed.ThisisoneofmyfirstdefectssoIhopeImgivingenoughdetailwithoutitalreadybeingaknownissue. Update- Wedidanexperiementwherewerepeatedlyranthejenkinscli.Wedidthisbecauseourjenkinsjobsutilizeitheavilyandweweresuspiciousitmightberelated.Foreveryjenkinsclicommandexecutedgeneratedanotheropenfilereferencethatdoesntappeartogetclosed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [other] (JENKINS-23572) Too many open files exception
Damon G updated JENKINS-23572 Too many open files exception Change By: Damon G (26/Jun/14 11:49 AM) Description: Wecanrunforabout2daysandthenthesystembasicallybecomesunresponsiveandneedstoberestarted.Everythingwasgoingfineformanymonthsatversion1.5.46butoncewewentto1.5.66or1.5.68webegintoseetoomanyopenfilesexceptionsuntiljenkinsneededarestart.Attachedarethestacktraces.IdidntchooseaspecificcomponentbecauseIwasntsurewhichcomponenttologitagainst.Ialsodontseeanyexistingopenissuesthatmatchthis.Hopeopeningthiswasvalid.Iveattachedalistofallfilesopened(usinglsof)byjenkinsaswellasthejenkinslogcontainingthestacktraces.IonlyincludedacoupleofthestacktracesbecauseIhaveafeelingtheoutputoflsofmaybemoreilluminating.Happytoprovideanythingmoreyouneed.ThisisoneofmyfirstdefectssoIhopeImgivingenoughdetailwithoutitalreadybeingaknownissue.Update-Wedidanexperiementwherewerepeatedlyranthejenkinscli.Wedidthisbecauseourjenkinsjobsutilizeitheavilyandweweresuspiciousitmightberelated.Foreveryjenkinsclicommandexecutedgeneratedanotheropenfilereferencethatdoesntappeartogetclosed. Itcorrespondstoentriesinlsoflikethis: java1230jenkins3772usock0,70t053062cantidentifyprotocol Itdoesntlooklikethisfilesareevergettingclosed. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [other] (JENKINS-23572) Too many open files exception
Damon G updated JENKINS-23572 Too many open files exception Change By: Damon G (26/Jun/14 11:51 AM) Description: Wecanrunforabout2daysandthenthesystembasicallybecomesunresponsiveandneedstoberestarted.Everythingwasgoingfineformanymonthsatversion1.5.46butoncewewentto1.5.66or1.5.68webegintoseetoomanyopenfilesexceptionsuntiljenkinsneededarestart.Attachedarethestacktraces.IdidntchooseaspecificcomponentbecauseIwasntsurewhichcomponenttologitagainst.Ialsodontseeanyexistingopenissuesthatmatchthis.Hopeopeningthiswasvalid.Iveattachedalistofallfilesopened(usinglsof)byjenkinsaswellasthejenkinslogcontainingthestacktraces.IonlyincludedacoupleofthestacktracesbecauseIhaveafeelingtheoutputoflsofmaybemoreilluminating.Happytoprovideanythingmoreyouneed.ThisisoneofmyfirstdefectssoIhopeImgivingenoughdetailwithoutitalreadybeingaknownissue.Update-Wedidanexperiementwherewerepeatedlyranthejenkinscli.Wedidthisbecauseourjenkinsjobsutilizeitheavilyandweweresuspiciousitmightberelated.Foreveryjenkinsclicommandexecutedgeneratedanotheropenfilereferencethatdoesntappeartogetclosed.Itcorrespondstoentriesinlsoflikethis:java1230jenkins3772usock0,70t053062cantidentifyprotocolItdoesntlooklikethisfilesareevergettingclosed. Ifyoulookinthatlsoffileyoullseeroughly11,000linesjustliketheoneabove. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [other] (JENKINS-23572) Too many open files exception
Damon G created JENKINS-23572 Too many open files exception Issue Type: Bug Affects Versions: current Assignee: Unassigned Attachments: jenkins_stack_trace.log, lsof.txt Components: other Created: 25/Jun/14 2:12 PM Description: We can run for about 2 days and then the system basically becomes unresponsive and needs to be restarted. Everything was going fine for many months at version 1.5.46 but once we went to 1.5.66 or 1.5.68 we begin to see too many open files exceptions until jenkins needed a restart. Attached are the stack traces. I didn't choose a specific component because I wasn't sure which component to log it against. I also don't see any existing open issues that match this. Hope opening this was valid. I've attached a list of all files opened (using lsof) by jenkins as well as the jenkins log containing the stack traces. I only included a couple of the stack traces because I have a feeling the output of lsof may be more illuminating. Happy to provide anything more you need. This is one of my first defects so I hope I'm giving enough detail without it already being a known issue. Environment: Ubuntu 12.04 50 + ssh ubuntu 12.04 slaves. Project: Jenkins Priority: Major Reporter: Damon G This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[JIRA] [maven] (JENKINS-18017) Attempting to specify a maven settings.xml in a freestyle job is ingored upon saving
Damon G created JENKINS-18017 Attempting to specify a maven settings.xml in a freestyle job is ingored upon saving Issue Type: Bug Affects Versions: current Assignee: Unassigned Components: maven Created: 21/May/13 1:39 AM Description: Something broke with respect to specifying a maven settings.xml file in a job sometime after 1.510. I am seeing the issue in 1.515. Any attempt to fill in the maven settings file field is ignored / overwritten with "use maven default" after hitting the save button. I've confirmed it in the jobs config.xml file. Reverting to 1.510 saves the change. At first I tried just reverting the maven plugin version from 1.515 to 1.510 and restarting jenkins but that wasn't enough to fix it. I had to revert war files back to 1.510. Full disclosure I haven't tried any builds in between because at the moment I only have a production server. The steps are fairly easy to reproduce: 1. Create a freestyle software project. 2. Make one of the build steps "Invoke Top level Maven target" 3. Set maven version to "maven" 4. Goals: I had typed "clean install" 5. Under advanced check "Use private maven repository" 6. -here's what's broken- Settings file set "Settings file in file system" 7.File Path: settings.xml 8 Global Settings file: "Use Default Maven global settings" 9. Click save. Save will appear to complete successfully but if you look at the xml file itself or go back to the configure page the settings file setting is set back to "use default maven settings". Environment: Ubuntu 64 VM Jenkins running behind Apache2 Jenkins version 1.515 Previously working in 1.510 - confirmed reverting to this build fixes it. --- System Properties --- xecutable-war /usr/share/jenkins/jenkins.war file.encoding UTF-8 file.encoding.pkg sun.io file.separator / hudson.diyChunking true java.awt.graphicsenv sun.awt.X11GraphicsEnvironment java.awt.headless true java.awt.printerjob sun.print.PSPrinterJob java.class.path /usr/share/jenkins/jenkins.war java.class.version 50.0 java.endorsed.dirs /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/endorsed java.ext.dirs /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/ext:/usr/java/packages/lib/ext java.home /usr/lib/jvm/java-6-sun-1.6.0.26/jre java.io.tmpdir /tmp/jenkins java.library.path /usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64/server:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/lib/amd64:/usr/lib/jvm/java-6-sun-1.6.0.26/jre/../lib/amd64:/lib:/usr/lib:/usr/local/staf/lib::/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib java.runtime.name Java(TM) SE Runtime Environment java.runtime.version 1.6.0_26-b03 java.specification.name Java Platform API Specification java.specification.vendor Sun Microsystems Inc. java.specification.version 1.6 java.vendor Sun Microsystems Inc. java.vendor.url http://java.sun.com/ java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi java.version 1.6.0_26 java.vm.info mixed mode java.vm.name Java HotSpot(TM) 64-Bit Server VM java.vm.specification.name Java Virtual Machine Specification java.vm.specification.vendor Sun Microsystems Inc. java.vm.specification.version 1.0 java.vm.vendor Sun Microsystems Inc. java.vm.version 20.1-b02 javamelody.analytics-id UA-1335263-7 javamelody.gzip-compression-disabled true javamelody.http-transform-pattern /\d+/|/site/.+|avadoc/.+|/ws/.+|obertura/.+|estReport/.+|iolations/file/.+|/user/.+|/static/\w+/|/adjuncts/\w+/|/bound/[\w\-]+ javamelody.no-database true javamelody.storage-directory //var/lib/jenkins/monitoring javamelody.system-actions-enabled true jna.platform.library.path /usr/lib/x86_64-linux-gnu:/lib/x86_64-linux-gnu:/usr/lib64:/lib64:/usr/lib:/lib line.separator mail.smtp.sendpartial true mail.smtps.sendpartial true os.arch amd64 os.name Linux os.version 2.6.38-8-server path.separator : pid 18823 sun.arch.data.model 64 sun.boot.class.path
[JIRA] (JENKINS-16264) Posting config.xml to master node advertised to work
Damon G commented on JENKINS-16264 Posting config.xml to master node advertised to work I have to take that comment back. It doesn't work. I thought it was working because my attempt above used cashed credentials I had open in another browser tab. I don't have CSRF enabled. I'll take it to the forums though. This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16264) Posting config.xml to master node advertised to work
Damon G commented on JENKINS-16264 Posting config.xml to master node advertised to work I think I understand both cases described here. It sounds similar but not identical something related I see. I thought I'd check before logging a separate defect. LDAP authentication is enabled on my master. I have an api token associated with my user. (I have admin privileges). I'm attempting to retrieve the config.xml for a particular computer using basic authentication in groovy. For instance: http://myjenkins/computer/a-slave-node-computername/config.xml?token=TOKEN I'm passing in my username and my token for the password field. I get a 403 error. I think what your saying is that I should be expecting a 403 unless the code was enhanced to allow a GET on the computer config using a token. I'm at build 1.505 Is this a separate issue or an RFE? Thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-16264) Posting config.xml to master node advertised to work
Damon G edited a comment on JENKINS-16264 Posting config.xml to master node advertised to work I think I understand both cases described here. It sounds similar but not identical something related I see. I thought I'd check before logging a separate defect. LDAP authentication is enabled on my master. I have an api token associated with my user. (I have admin privileges). I'm attempting to retrieve the config.xml for a particular computer using basic authentication in groovy. For instance: http://myjenkins/computer/a-slave-node-computername/config.xml?token=TOKEN I'm passing in my username and my token for the password field. I get a 403 error. I think what your saying is that I should be expecting a 403 unless the code was enhanced to allow a GET on the computer config using a token. I'm at build 1.505 Is this a separate issue or an RFE? I realize the error described above is not a 403 but another exception. I still wasn't sure if that was because the GET was attempted for the master...and in my case it's a request for slave node configuration. Thanks! This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira -- You received this message because you are subscribed to the Google Groups Jenkins Issues group. To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
[JIRA] (JENKINS-15370) Node Label Parementer Plugin - Value of Node param variable doesnt contain all values when multiselecting nodes
Damon G
created JENKINS-15370
Node Label Parementer Plugin - Value of Node param variable doesnt contain all values when multiselecting nodes
Issue Type:
Bug
Assignee:
domi
Components:
nodelabelparameter
Created:
01/Oct/12 4:33 PM
Description:
Summary: When selecting multiple nodes for parallel execution, the values selected at build time cannot be properly retrieved from the environment variable.
Steps to reproduce:
1. Create a parameterized build that contains a Node parameter named HOSTS. 2. Select "Allow multi node selection for concurrent builds"
3. Checked the box further down to allow executing concurrent builds.
4. Create a system groovy script to print the values of the nodes selected. Here's the script:
import hudson.model.*
import hudson.util.*
def build = Thread.currentThread().executable
def resolver = build.buildVariableResolver
def chosenHosts = resolver.resolve("HOSTS")
println "HOSTS from System Groovy Script= " + chosenHosts
When I build I select 2 nodes from my list of available nodes( node1 and node2). It builds and executes on both nodes.
However the value of chosenHosts in the job that ran on node1 prints a value of node1
The job that executed on node2 prints a value of null.
What I expected was that the value of chosenHosts would be "node1, node2".
Note: This is in a system groovy script, so this build step is executing on the master.
Environment:
Linux Master and Slaves
Project:
Jenkins
Labels:
plugin
Priority:
Major
Reporter:
Damon G
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira
