[JIRA] (JENKINS-36885) AVD not being created
Title: Message Title Richard Mortimer commented on JENKINS-36885 Re: AVD not being created I came across a similar failure earlier today. In my case it was due to having specified an invalid display configuration for the emulator. This resulted in the "create avd" command failing. Having looked at the code the emulator plugin only reports the output (either stderr or stdout) in very specific cases. This hides the cause of the failure. In addition the "Failed to parse AVD config file" failure is just a symptom of the problem because there is no configuration file to parse. I have prepared a patch that improves error logging. See https://github.com/jenkinsci/android-emulator-plugin/pull/62 Add Comment This message was sent by Atlassian JIRA (v7.1.7#71011-sha1:2526d7c) -- 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] [android-emulator-plugin] (JENKINS-28067) android emulator fails to start error: device offline
Richard Mortimer created JENKINS-28067 android emulator fails to start error: device offline Issue Type: Bug Assignee: Richard Mortimer Components: android-emulator-plugin Created: 23/Apr/15 1:25 PM Description: A bit more evidence in the long running saga of Android emulator failing to start properly. I have started a new issue but this is closely related to JENKINS-11952 Notes: The information below was gathered using plugin 2.12. That would fail often enough for me that I could get some slow debug. I'm pretty sure that what I've found will apply to 2.13 and onwards. I'm personally not convinced that switching back to the localhost: method of connection is 100% safe given my previous investigations for JENKINS-12821 but that is a different matter. For those who do not want to try to understand the logs below then the short story is that I suspect that the android-emulator-plugin is causing the emulator-ADB connection to lock up by connecting to the emulator ADB port to check whether it has started up. It maybe that the lockup would happen anyway but I think we can remove the waitForSocket (and subsequent single ADB connect - if using the emulator- connection) without any adverse effects on the startup procedure. I do not have a sample pull request yet but I have a modified version of 2.12 running locally and will see if my once/twice daily lockups continue to happen. Only the brave need read below... Below is the TCP traffic to the emulator ADB port (5561 in this instance) on a startup that fails. I have a number of examples of this with the same symptoms. richm@bishop:~$ tcpdump -r /tmp/150423_android1.pcap port 5561 reading from file /tmp/150423_android1.pcap, link-type LINUX_SLL (Linux cooked) = ADB server connects here (port 60975) 10:44:18.487165 IP localhost.60975 localhost.5561: Flags [S], seq 3774551783, win 43690, options [mss 65495,sackOK,TS val 791658429 ecr 0,nop,wscale 7], length 0 10:44:18.487183 IP localhost.5561 localhost.60975: Flags [R.], seq 0, ack 3774551784, win 0, length 0 10:44:25.247907 IP localhost.32808 localhost.5561: Flags [S], seq 1102610480, win 43690, options [mss 65495,sackOK,TS val 791660119 ecr 0,nop,wscale 7], length 0 10:44:25.247950 IP localhost.5561 localhost.32808: Flags [S.], seq 869467149, ack 1102610481, win 43690, options [mss 65495,sackOK,TS val 791660119 ecr 791660119,nop,wscale 7], length 0 10:44:25.247987 IP localhost.32808 localhost.5561: Flags [.], ack 1, win 342, options [nop,nop,TS val 791660119 ecr 791660119], length 0 = ADB server sends start of CNXN handshake 10:44:25.252799 IP localhost.32808 localhost.5561: Flags [P.], seq 1:32, ack 1, win 342, options [nop,nop,TS val 791660121 ecr 791660119], length 31 10:44:25.252886 IP localhost.5561 localhost.32808: Flags [.], ack 32, win 342, options [nop,nop,TS val 791660121 ecr 791660121], length 0 = Jenkins android plugin tests for emulator adb port alive = When things go wrong the emulator seems to ignore this for a while 10:44:26.651163 IP localhost.32810 localhost.5561: Flags [S], seq 571765708, win 43690, options [mss 65495,sackOK,TS val 791660470 ecr 0,nop,wscale 7], length 0 10:44:26.651200 IP localhost.5561 localhost.32810: Flags [S.], seq 2069788705, ack 571765709, win 43690, options [mss 65495,sackOK,TS val 791660470 ecr 791660470,nop,wscale 7], length 0 10:44:26.651237 IP localhost.32810 localhost.5561: Flags [.], ack 1, win 342, options [nop,nop,TS val 791660470 ecr 791660470], length 0 = Jenkins android plugin immediately closes connection = Emulator looks to be sitting waiting for CNXN handshake 10:44:26.651407 IP localhost.32810 localhost.5561: Flags [F.], seq 1, ack 1, win 342, options [nop,nop,TS val 791660470 ecr 791660470], length 0 10:44:26.652528 IP localhost.5561 localhost.32810: Flags [.], ack 2, win 342, options [nop,nop,TS val 791660471 ecr 791660470], length 0 10:45:41.012188 IP localhost.5561 localhost.32808: Flags [F.], seq 1, ack 32, win 342, options [nop,nop,TS val 791679060 ecr 791660121], length 0 = ADB server gives up waiting for CNXN handshake
[JIRA] [core] (JENKINS-26520) Environment Variables BUILD_ID and BUILD_NUMBER now return the same value
Richard Mortimer commented on JENKINS-26520 Environment Variables BUILD_ID and BUILD_NUMBER now return the same value Jesse, What are your plans in respect of this issue? I've applied the Groovy script workaround to inject BUILD_TIMESTAMP into my builds and have adjusted usage of BUILD_ID to match. That all works fine. If that is going to be the recommended way to fixup affected systems then personally I am fine with that and I would suggest that this issue will be closed as will not fix with the workaround documented. If the intention is to add a BUILD_TIMESTAMP variable parallel to BUILD_ID then I will adapt my earlier fix if you do not have the bandwidth to do that. 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-plugin] (JENKINS-26777) Build reports to be running for 45 yr and counting
Richard Mortimer assigned JENKINS-26777 to Richard Mortimer Build reports to be running for 45 yr and counting Change By: Richard Mortimer (30/Mar/15 12:18 PM) Assignee: RichardMortimer 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-plugin] (JENKINS-26777) Build reports to be running for 45 yr and counting
Richard Mortimer commented on JENKINS-26777 Build reports to be running for 45 yr and counting The problem occurs because getDurationString in hudson.model.Run is calculating a duration before a build has actually started. In that case starttime is zero and hence the build time is reported as the time since the unix epoch (1970). I do not think that anything parses the time so I'd propose that we return "Not started yet" if the build has not started running. 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] [core] (JENKINS-26520) Environment Variables BUILD_ID and BUILD_NUMBER now return the same value
Richard Mortimer commented on JENKINS-26520 Environment Variables BUILD_ID and BUILD_NUMBER now return the same value I think BUILD_ID should keep the timestamp format. That is the documented behaviour at https://wiki.jenkins-ci.org/display/JENKINS/Building+a+software+project The BUILD_NUMBER variable gives the build number still. The change of format has broken a couple of my deployment scripts that were expecting the date format. I did a quick fix to use the old formatting code and that seems to have made things work for me. I have not submitted a pull request because I have not had chance to fully test things. For those who are interested the code is at https://github.com/oldelvet/jenkins/tree/jenkins-26520 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] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Richard Mortimer commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot Relevant bits from the thread dump. NioChannelHub (and a few other things not included for compactness) are waiting on Channel@2323a3cd NioChannelHub keys=4 gen=5352736: Computer.threadPoolForRemoting [#2] "NioChannelHub keys=4 gen=5352736: Computer.threadPoolForRemoting [#2]" Id=144 Group=main BLOCKED on hudson.remoting.Channel@2d23a3cd owned by "Finalizer" Id=3 at hudson.remoting.Channel.terminate(Channel.java:804) - blocked on hudson.remoting.Channel@2d23a3cd at hudson.remoting.Channel$2.terminate(Channel.java:491) at hudson.remoting.AbstractByteArrayCommandTransport$1.terminate(AbstractByteArrayCommandTransport.java:72) at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:211) at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:631) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source) at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source) at java.util.concurrent.FutureTask.run(Unknown Source) at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Number of locked synchronizers = 1 - java.util.concurrent.ThreadPoolExecutor$Worker@1b9eef5 this is held by the Finalizer that is waiting on FifoBuffer@782372ec Finalizer "Finalizer" Id=3 Group=system WAITING on org.jenkinsci.remoting.nio.FifoBuffer@782372ec at java.lang.Object.wait(Native Method) - waiting on org.jenkinsci.remoting.nio.FifoBuffer@782372ec at java.lang.Object.wait(Object.java:503) at org.jenkinsci.remoting.nio.FifoBuffer.write(FifoBuffer.java:336) at org.jenkinsci.remoting.nio.FifoBuffer.write(FifoBuffer.java:324) at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.writeBlock(NioChannelHub.java:222) at hudson.remoting.AbstractByteArrayCommandTransport.write(AbstractByteArrayCommandTransport.java:83) at hudson.remoting.Channel.send(Channel.java:553) - locked hudson.remoting.Channel@2d23a3cd at hudson.remoting.RemoteInvocationHandler.finalize(RemoteInvocationHandler.java:240) at java.lang.ref.Finalizer.invokeFinalizeMethod(Native Method) at java.lang.ref.Finalizer.runFinalizer(Unknown Source) at java.lang.ref.Finalizer.access$100(Unknown Source) at java.lang.ref.Finalizer$FinalizerThread.run(Unknown Source) It looks like the Finalizer is trying to write to a channel to cleanup an object with remote state and has effectively locked things up because nothing can come along and force the FifoBuffer write to terminate. 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] [core] (JENKINS-25490) Slave agent run with javaws breaks with Unable to launch the application when master is stopped
Richard Mortimer commented on JENKINS-25490 Slave agent run with javaws breaks with Unable to launch the application when master is stopped I'm glad it is fixed. I wonder if the failure was occurring because JWS was trying to re-download the .jnlp file but couldn't because the master was restarting. The fix for JENKINS-24272 only restarts the slave when the master has restarted so the .jnlp file would be available then. 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] [core] (JENKINS-25490) Slave JLNP client stops working with Unable to launch the application when master is stopped
Richard Mortimer commented on JENKINS-25490 Slave JLNP client stops working with Unable to launch the application when master is stopped I suspect that the changes that made this happen are related to those that caused JENKINS-24272 but it is not the same failure. Namely between 1.554.3 and 1.565.1 Jenkins now restarts the whole slave process when the master restarts (to ensure that any memory leaks are gone) rather than just reconnecting to the master. Now it looks to me that JWS is deleting the downloaded file (slave.jar I would guess) and hence when the slave tries to restart it cannot find the executed file and hence the error seen occurs. This delete downloaded file behaviour is typical for what a web launched application would do to stop filling up the disk with unneeded junk. That might just be at odds with the whole restart JVM (as opposed to reconnect to master) approach. 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Richard Mortimer commented on JENKINS-24272 jnlp slaves fail to reconnect when master is restarted Looks like my pull request https://github.com/jenkinsci/jenkins/pull/1393 is still waiting to be merged. I'll give it a prod. 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] [debian-package-builder] (JENKINS-24906) Debian package LTS v1.565.2 has corrupt jenkins.war
Richard Mortimer commented on JENKINS-24906 Debian package LTS v1.565.2 has corrupt jenkins.war The contents of the changelog should be available for viewing via zless /usr/share/doc/jenkins/changelog.gz 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] [debian-package-builder] (JENKINS-24906) Debian package LTS v1.565.2 has corrupt jenkins.war
Richard Mortimer commented on JENKINS-24906 Debian package LTS v1.565.2 has corrupt jenkins.war I don't see any corruption in the Debian package. The md5sums are correct compared against downloaded war files and the information contained within the .deb. Are you sure that you have the right version installed? $ mkdir /tmp/jenkins $ cd /tmp/jenkins $ wget http://pkg.jenkins-ci.org/debian-stable/binary/jenkins_1.565.2_all.deb $ mkdir jenkins_1.565.2_all $ dpkg-deb -R jenkins_1.565.2_all.deb jenkins_1.565.2_all $ wget http://mirrors.jenkins-ci.org/war-stable/latest/jenkins.war $ wget -O jenkins-1.565.2.war http://mirrors.jenkins-ci.org/war-stable/1.565.2/jenkins.war $ md5sum jenkins.war jenkins-1.565.2.war jenkins_1.565.2_all/usr/share/jenkins/jenkins.war e53d793e42d1686ab103960dbd17979a jenkins.war e53d793e42d1686ab103960dbd17979a jenkins-1.565.2.war e53d793e42d1686ab103960dbd17979a jenkins_1.565.2_all/usr/share/jenkins/jenkins.war $ grep jenkins.war jenkins_1.565.2_all/DEBIAN/md5sums e53d793e42d1686ab103960dbd17979a usr/share/jenkins/jenkins.war 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] [debian-package-builder] (JENKINS-24906) Debian package LTS v1.565.2 has corrupt jenkins.war
Richard Mortimer commented on JENKINS-24906 Debian package LTS v1.565.2 has corrupt jenkins.war I just spotted Daniel's comment about jenkins-common. The fact that /var/lib/dpkg/info/jenkins-common.md5sums exists suggests that it is the Debian distribution package that is installed and not the upstream packaged version. This is confirmed by checking the Debian distribution .deb file $ wget http://ftp.uk.debian.org/debian/pool/main/j/jenkins/jenkins-common_1.565.2-2_all.deb s$ mkdir jenkins-common_1.565.2-2_all $ dpkg-deb -R jenkins-common_1.565.2-2_all.deb jenkins-common_1.565.2-2_all $ md5sum jenkins-common_1.565.2-2_all/usr/share/jenkins/jenkins.war 2cc48f1f0341b8c54659e0af73cc3115 jenkins-common_1.565.2-2_all/usr/share/jenkins/jenkins.war $ grep jenkins.war jenkins-common_1.565.2-2_all/DEBIAN/control md5sums $ grep jenkins.war jenkins-common_1.565.2-2_all/DEBIAN/md5sums 2cc48f1f0341b8c54659e0af73cc3115 usr/share/jenkins/jenkins.war Conclusion this is a Debian project issue and not a Jenkins upstream issue. 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Richard Mortimer commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed @Arnt Witteveen I agree it would be nice if it could withstand a network outage of a minute or so but there are a few technical challenges to overcome which make this non-trivial. In theory things should survive for a brief network outage and indeed they do on a linux-to-linux master/slave arrangement but windows seems to be much more aggressive in closing down TCP connections and hence the windows side of things has gone before the network connection has been restored. I believe that making the low level protocol cope with a break of the TCP connection is non-trivial. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb You should only need to set the ADB_TRACE environment variable in Jenkins. The android-emulator-plugin starts ADB from within the job and kills it at the end. Ideally you should make sure that no other ADB server/emulator instance is running outside of jenkins to avoid complicating things. It does make sense to ensure that /tmp/adb.log does not exist before the jenkins job starts to ensure that there are no file permissions issues when the ADB server tries to open the log. I don't think that the emulator loglevel change would be useful at this time. 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] [master-slave] (JENKINS-23852) slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed
Richard Mortimer commented on JENKINS-23852 slave builds repeatedly broken by hudson.remoting.ChannelClosedException: channel is already closed I have been seeing similar problems to this. In my situation one of my slaves is a Windows 7 desktop computer that is set to suspend after a period of inactivity. I've had this running for a few years without problem and the slave has always reconnected successfully when the desktop is woken up. However since the NIO selector thread has been introduced the slaves have ended up being offline for prolonged periods of time and require a manual restart of the Jenkins slave service to bring them back online (see JENKINS-24272). One other symptom that I have observed during testing of this is the server rejecting connections similar to that reported here namely: Jul 16, 2014 9:07:06 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: The server rejected the connection: XXX is already connected to this master. Rejecting this connection. java.lang.Exception: The server rejected the connection: XXX is already connected to this master. Rejecting this connection. at hudson.remoting.Engine.onConnectionRejected(Engine.java:304) at hudson.remoting.Engine.run(Engine.java:276) Having investigated I'm seeing that the slave has decided that the connection is broken and has tore down its TCP connection to the master but the master never sees the TCP RST for this so it continues to retry the TCP packets for 10 or so minutes until the TCP connection times out and then the master tears down the connection. The really strange this is that this behaviour seems to be different between NIO and threaded methods on the master. With threaded the TCP RST is sent by W7 and kills the connection before the slave reconnects but in NIO no RST is ever sent. That happens down at the network packet level so it shouldn't really be affected by NIO but I wonder if it a slight different configuration in the network stack (non-blocking vs blocking) that causes the different behaviour. I also suspect that this may be related to the change to re-start JNLP slaves using a new JVM rather than just restarting in the same process. It may be that the Windows TCP stack just immediately forgets the old TCP socket when the old JVM process exits and hence ignores retries rather than RSTing the connection. I'm planning on waiting for the current crop of JNLP slave fixes to get integrated and will then experiment a bit further to see if I can work out what is stopping the NIO selector getting notified that the slave has closed the TCP connection. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb The bad_adb.log file does not look like what I expected at all. It seems to be logging socket level information but not adb or transport. It maybe that things operate differently on OS X but if you could check that you did capture the log at the correct level please. It might also be worth making /tmp/adb.log world writeable, chmod a+x /tmp/adb.log, just in case there is something else creating the log first. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb can you grab /tmp/adb.log too please. That will have the more interesting ADB server side of the story. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Given the error symptoms it looks like we can enable to tracing in ADB to get it to tell more information about what is going on. Just set the environment variable ADB_TRACE to adb,transport for the job (or as a global environment variable in the jenkins configuration) 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer edited a comment on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Given the error symptoms it looks like we can enable to tracing in ADB to get it to tell more information about what is going on. Just set the environment variable ADB_TRACE to adb,transport for the job (or as a global environment variable in the jenkins configuration). You might need the EnvInject plugin installed to do this. Now when the build runs it will log additional information in the console output. The ADB server will also log to /tmp/adb.log. That location is hardcoded and cannot be changed so you need to grab that after the build. Also make sure that you remove it before the next build or it will append the new log onto the end. If it is configured right you will see lots of messages similar to the following: system/core/adb/adb_client.c::_adb_connect():_adb_connect: return fd 3 system/core/adb/adb_client.c::adb_connect():adb_connect: return fd 3 system/core/adb/transport.c::readx():readx: fd=3 wanted=4 system/core/adb/transport.c::readx():readx: fd=3 wanted=4 got=4 30303237 0027 I don't really think you need to capture the "good" logs anymore we have enough examples of that so you might as well save some uploading time. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Do you have the console and logcat output logs for each of the good and bad examples? That would help to match things up with events in the packet capture. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb I've had a quick look over the Wireshark captures. In the "bad" capture the emulator never responds to the connection (CNXN) request from ADB and at first glance that seems to jam the whole adb-emulator connection up. I haven't worked out whether ADB or the emulator is a fault because ADB only gives the emulator about 0.5 second to respond before it forcefully closes the connection. The emulator doesn't release (TCP FIN) its end of the connection for about another 17 seconds. For reference this all occurs in the TCP connection from port 62625 to port 5752 that starts at packet 371 in the bad pcap file. Good connection looks like 43 4e 58 4e 00 00 00 01 00 10 00 00 07 00 00 00 CNXN 0010 32 02 00 00 bc b1 a7 b1 68 6f 73 74 3a 3a 002... host::. 43 4e 58 4e 00 00 00 01 00 10 00 00 5a 00 00 00 CNXN Z... 0010 41 22 00 00 bc b1 a7 b1 64 65 76 69 63 65 3a 3a A".. device:: 0020 72 6f 2e 70 72 6f 64 75 63 74 2e 6e 61 6d 65 3d ro.produ ct.name= 0030 67 6f 6f 67 6c 65 5f 73 64 6b 3b 72 6f 2e 70 72 google_s dk;ro.pr 0040 6f 64 75 63 74 2e 6d 6f 64 65 6c 3d 67 6f 6f 67 oduct.mo del=goog 0050 6c 65 5f 73 64 6b 3b 72 6f 2e 70 72 6f 64 75 63 le_sdk;r o.produc 0060 74 2e 64 65 76 69 63 65 3d 67 65 6e 65 72 69 63 t.device =generic 0070 3b 00;. 001F 4f 50 45 4e 17 00 00 00 00 00 00 00 1f 00 00 00 OPEN 002F ed 0b 00 00 b0 af ba b1 73 68 65 6c 6c 3a 67 65 shell:ge 003F 74 70 72 6f 70 20 64 65 76 2e 62 6f 6f 74 63 6f tprop de v.bootco 004F 6d 70 6c 65 74 65 00 mplete. 0072 4f 4b 41 59 01 00 00 00 17 00 00 00 00 00 00 00 OKAY 0082 00 00 00 00 b0 b4 be a6 008A 57 52 54 45 01 00 00 00 17 00 00 00 02 00 00 00 WRTE 009A 17 00 00 00 a8 ad ab ba 0d 0a .. 0056 4f 4b 41 59 17 00 00 00 01 00 00 00 00 00 00 00 OKAY 0066 00 00 00 00 b0 b4 be a6 00A4 43 4c 53 45 00 00 00 00 17 00 00 00 00 00 00 00 CLSE 00B4 00 00 00 00 bc b3 ac ba 006E 43 4c 53 45 17 00 00 00 01 00 00 00 00 00 00 00 CLSE 007E 00 00 00 00 bc b3 ac ba ... truncated here because it is uninteresting for our purposes... Bad connection stream contains 43 4e 58 4e 00 00 00 01 00 10 00 00 07 00 00 00 CNXN 0010 32 02 00 00 bc b1 a7 b1 68 6f 73 74 3a 3a 002... host::. I likely will not get to look at this further for at least the next 36 hours. I will do a bit of digging in the emulator/ADB code to see if my analysis matches what the code does once I get some spare time. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Tobias, first point I would expect adb in the terminal to report offline too. The adb command connects to the adb server to find out that information so it should be consistent. I think you just said that there is only one adb server process running but it would be good to confirm that to ensure that the emulator is not managing to talk to another instance of adb. tcpdump option I have never tried the -tcpdump option so I cannot comment. But I do believe that it only captures the emulator's virtual Ethernet LAN so I would not expect it to capture the communications with ADB. Where did you ask -tcpdump to save the PCAP file to? You probably need to specify a full pathname and make sure that it is writable. Maybe try a file in /Users/Share/Jenkins/tmp/ as that is your tmpdir specified in your Jenkins commandline. setup My master is installed on an Ubuntu 14.04 server using the standard .deb packaging. The android emulator runs on a Ubuntu 14.04 slave connected via jnlp that is launched using /usr/bin/java -Xms256m -Xmx512m -jar /usr/share/jenkslav/slave.jar -jnlpUrl file:///opt/jenkins/slave/slave-agent.jnlp I have in the past used a Windows 7 slave machine (installed as a service) connecting via jnlp for the emulator. But most of my recent usage/testing has been on Ubuntu 14.04. I've never tried running a slave/emulator on MacOS X so that may explain the different experience that you have. wireshark/tcpdump If you can try again with wireshark (or commandline tcpdump) to capture the traffic between adb and the emulator that should help to diagnose the problem. The two will communicate via localhost (127.0.0.1) so you will need to make sure that you are capturing on that interface and not on a LAN. I would suggest that you capture all traffic and then filter for the ports used by adb/emulator after the build has failed. I'll happily have a look at the filtered capture but I would suggest that you zip/email it direct to me rather than posting somewhere public. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer
commented on JENKINS-11952
Emulator occasionally hangs indefinitely on startup, unable to connect adb
Tobias can you post a "good" log too. That would be helpful for myself/others to make sense of the various warnings/errors in the log that are just "normal".
That said around like 2834 of your log the following exists
D/AlertReceiver( 1323): onReceive: a=android.intent.action.BOOT_COMPLETED Intent { act=android.intent.action.BOOT_COMPLETED flg=0x810 cmp=com.android.calendar/.alerts.AlertReceiver (has extras) }
I/ActivityManager( 384): Delay finish: com.android.calendar/.alerts.AlertReceiver
D/AlertUtils( 1323): Flushing old alerts from shared prefs table
D/AlertService( 1323): 0 Action = ""
This suggests to me that the emulator thinks that boot has completed but that it is not connected to ADB properly. That would add some weight to the theory that something is going wrong in the early emulator-ADB communications.
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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Tobias thanks for posting your logs. This does look very much like the original problem that has been reported. It looks like the emulator does do the initial attach to ADB but then never transitions to online state. I don't think the emulator is crashing/exiting because that would cause the listing in devices -l to go away. Did you get a logcat file archived for one of the failed jobs? It doesn't look like it did. Do you have access to any of the Mac OS system logs? If so it would be a good idea to have a look in them to see if there are any "interesting" events around the time of the failure. There may be out-of-memory issues or other system resource starvation issues that could cause a strange failure mode. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb @Guillaume that output shows that the emulator is starting up and is correctly attaching to adb. For some reason the emulator is then failing to complete the boot. I think your scenario should be tracked as a separate issue (to avoid things getting too complex). I guess that the build will not have captured any logcat output before failure. The next step in debugging your problem might be to capture it and see if there is anything of interest in the logs. 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] [core] (JENKINS-24316) Plugin icons do not show in left navigation: duplicate slash before plugin path in image URL
Richard Mortimer commented on JENKINS-24316 Plugin icons do not show in left navigation: duplicate slash before plugin path in image URL Tested with latest git and the images are now properly displayed including the /static/ prefix to help with caching. 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/d/optout.
[JIRA] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb I extended my patch series to capture logcat output irrespective of whether boot completes or not. The change was quite simple although I did have to put a short delay in to allow the logcat output to be captured before the emulator was killed after a failed boot. A test build can be downloaded from android-emulator-2.12-SNAPSHOT.hpi Pull request at https://github.com/jenkinsci/android-emulator-plugin/pull/39 Note the pull request still contains the devices -l output. For now I think that will be useful in diagnosing the various causes of boot failures that may be out there. I'm not sure whether it just makes the logs too messy to be included long term. I'm also considering getting rid of the connect and disconnect operations. I don't think they add anything to the robustness of startup now we are using the emulator- style device name. 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] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Richard Mortimer commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot One potential workaround to try is adding -Djenkins.slaves.NioChannelSelector.disabled=true onto the Jenkins master's launcher command line arguments. On Debian/Ubuntu that is as simple as adding the above to JAVA_ARGS in /etc/default/jenkins If launching jenkins from the commandline it would be java -Djenkins.slaves.NioChannelSelector.disabled=true -jar jenkins.war I just tested this on my system and it does seem to change the behaviour when I run my test case. In 3 tests the slave continued working correctly on 3 occassions. 2 of these saw the queued traffic just delivered and things continued as before. In the other example the original TCP connection entered TIME_WAIT state and a new connection was started successfully by the recently suspended slave. Wed Aug 20 11:18:23 BST 2014 tcp6 0 0 :::42715:::*LISTEN tcp6 0 0 192.168.1.23:42715 192.168.1.115:50570 TIME_WAIT tcp6 0 0 192.168.1.23:42715 192.168.1.24:47835 ESTABLISHED tcp6 0 0 192.168.1.23:42715 192.168.1.115:50619 ESTABLISHED From this I suspect that the new NIO based method of communicating with slaves is not causing the full TCP socket to get closed until TCP timers timeout. Whereas in the thread-per-slave method the connection is tore down almost immediately. It would be good to know if the NioChannelSelector workaround outlined above helps others. 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] [core] (JENKINS-20858) Images missing from Jenkins UI
Richard Mortimer commented on JENKINS-20858 Images missing from Jenkins UI This doesn't look like the same problem. The URL you included looks to be wrong there should be something between the "//" at the start of the URL. This needs logging as a separate issue probably against the config-rotator plugin. 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] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Richard Mortimer commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot I've seen the same issue on a Windows slave running a self-built version of 1.577-SNAPSHOT. The slave error log suggests that slave saw a connection reset but when it reconnected the master thought the slave was still connected and connection retries failed. Aug 17, 2014 11:05:02 PM hudson.remoting.SynchronousCommandTransport$ReaderThread run SEVERE: I/O error in channel channel java.net.SocketException: Connection reset at java.net.SocketInputStream.read(Unknown Source) at java.net.SocketInputStream.read(Unknown Source) at java.io.BufferedInputStream.fill(Unknown Source) at java.io.BufferedInputStream.read(Unknown Source) at hudson.remoting.FlightRecorderInputStream.read(FlightRecorderInputStream.java:82) at hudson.remoting.ChunkedInputStream.readHeader(ChunkedInputStream.java:67) at hudson.remoting.ChunkedInputStream.readUntilBreak(ChunkedInputStream.java:93) at hudson.remoting.ChunkedCommandTransport.readBlock(ChunkedCommandTransport.java:33) at hudson.remoting.AbstractSynchronousByteArrayCommandTransport.read(AbstractSynchronousByteArrayCommandTransport.java:34) at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:48) Aug 17, 2014 11:05:02 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated Aug 17, 2014 11:05:12 PM jenkins.slaves.restarter.JnlpSlaveRestarterInstaller$2$1 onReconnect INFO: Restarting slave via jenkins.slaves.restarter.WinswSlaveRestarter@5f849b Aug 17, 2014 11:05:17 PM hudson.remoting.jnlp.Main createEngine INFO: Setting up slave: Cygnet Aug 17, 2014 11:05:17 PM hudson.remoting.jnlp.Main$CuiListener init INFO: Jenkins agent is running in headless mode. Aug 17, 2014 11:05:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://jenkins.example/] Aug 17, 2014 11:05:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to jenkins.example:42715 Aug 17, 2014 11:05:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Aug 17, 2014 11:05:17 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: The server rejected the connection: Cygnet is already connected to this master. Rejecting this connection. java.lang.Exception: The server rejected the connection: Cygnet is already connected to this master. Rejecting this connection. at hudson.remoting.Engine.onConnectionRejected(Engine.java:306) at hudson.remoting.Engine.run(Engine.java:276) Aug 17, 2014 11:06:17 PM hudson.remoting.jnlp.Main createEngine INFO: Setting up slave: Cygnet Aug 17, 2014 11:06:17 PM hudson.remoting.jnlp.Main$CuiListener init INFO: Jenkins agent is running in headless mode. Aug 17, 2014 11:06:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://jenkins.example/] Aug 17, 2014 11:06:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to jenkins.example:42715 Aug 17, 2014 11:06:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Aug 17, 2014 11:06:17 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: The server rejected the connection: Cygnet is already connected to this master. Rejecting this connection. java.lang.Exception: The server rejected the connection: Cygnet is already connected to this master. Rejecting this connection. at hudson.remoting.Engine.onConnectionRejected(Engine.java:306) at hudson.remoting.Engine.run(Engine.java:276) Aug 17, 2014 11:07:18 PM hudson.remoting.jnlp.Main createEngine INFO: Setting up slave: Cygnet Aug 17, 2014 11:07:18 PM hudson.remoting.jnlp.Main$CuiListener init INFO: Jenkins agent is running in headless mode. Aug 17, 2014 11:07:18 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://jenkins.example/] Aug 17, 2014 11:07:18 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to jenkins.example:42715 Aug 17, 2014 11:07:18 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Handshaking Aug 17, 2014 11:07:18 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: The server rejected the connection: Cygnet is already connected to this master. Rejecting this connection. java.lang.Exception: The server rejected the connection: Cygnet is already connected to this master. Rejecting this connection. at hudson.remoting.Engine.onConnectionRejected(Engine.java:306) at hudson.remoting.Engine.run(Engine.java:276) After 3 retries at
[JIRA] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Richard Mortimer commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot I wonder whether this issue is related to the changes make circa 4th April 2014 to change JNLP slaves to use NIO. See commit d4c74bf35d4 in 1.599 andalso the corresponding changes made in remoting 2.38. May also be related to JENKINS-23248 but my build was definitely using the integrated fixes for that so it cannot be the whole solution. 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] [core] (JENKINS-24316) Plugin icons do not show in left navigation: duplicate slash before plugin path in image URL
Richard Mortimer commented on JENKINS-24316 Plugin icons do not show in left navigation: duplicate slash before plugin path in image URL I'm running a private build based off of commit 3efe07f563d30a3 (dated 14/August) Jenkins ver. 1.577-SNAPSHOT (private-08/19/2014 17:48 GMT-laptop) and still see the problem. I have confirmed and it does include commit 6f87e61ebe6ecd that mentions a fix for JENKINS-24181 I see the problem with both disk-usage-plugin 0.24 and safe-restart-plugin 0.3 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] [core] (JENKINS-24155) Jenkins Slaves Go Offline In Large Quantities and Don't Reconnect Until Reboot
Richard Mortimer commented on JENKINS-24155 Jenkins Slaves Go Offline In Large Quantities and Dont Reconnect Until Reboot After a bit of experimenting I can reproduce this scenario fairly easily using a Ubuntu 12.04 master and a Windows 7 slave (both using java 7). Once the slave is connected I forcibly suspend the windows 7 computer and monitor the TCP connection between the master and slave (on the master) using netstat. netstat -na | grep 42715 tcp6 0 0 :::42715:::*LISTEN tcp6 0 0 192.168.1.23:42715 192.168.1.24:58905 ESTABLISHED tcp6 0 2479 192.168.1.23:42715 192.168.1.115:61283 ESTABLISHED When the master attempts to "ping" the slave the slave does not respond and the TCP send queue builds up (2479 in the example above). Once the queue has been building for a few minutes bring the Windows 7 machine back to life and let things recover naturally. I observe that the Windows 7 machine issues a TCP RST on the connection. But the Linux master does not seem to react to the RST and continues to add data into the send queue. During this time the slave has attempted to restart the connection and failed because the master thinks that the slave is still connected. The windows slave service stops attempting a restart after a couple of failures. After a few minutes the channel pinger on the master declares that the slave is dead Aug 19, 2014 9:34:24 PM hudson.slaves.ChannelPinger$1 onDead INFO: Ping failed. Terminating the channel. java.util.concurrent.TimeoutException: Ping started on 1408480224640 hasn't completed at 1408480464640 at hudson.remoting.PingThread.ping(PingThread.java:120) at hudson.remoting.PingThread.run(PingThread.java:81) But even at this time the TCP stream stays open the slave connection is continuing to operate. After a further 10 minutes the connection does close. It seems like this is a standard TCP timeout. WARNING: Communication problem java.io.IOException: Connection timed out at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:136) at org.jenkinsci.remoting.nio.FifoBuffer.receive(FifoBuffer.java:306) at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:514) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Aug 19, 2014 9:44:13 PM jenkins.slaves.JnlpSlaveAgentProtocol$Handler$1 onClosed WARNING: NioChannelHub keys=2 gen=2823: Computer.threadPoolForRemoting [#2] for + Cygnet terminated java.io.IOException: Failed to abort at org.jenkinsci.remoting.nio.NioChannelHub$NioTransport.abort(NioChannelHub.java:195) at org.jenkinsci.remoting.nio.NioChannelHub.run(NioChannelHub.java:581) at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask.run(FutureTask.java:262) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:744) Caused by: java.io.IOException: Connection timed out at sun.nio.ch.FileDispatcherImpl.read0(Native Method) at sun.nio.ch.SocketDispatcher.read(SocketDispatcher.java:39) at sun.nio.ch.IOUtil.readIntoNativeBuffer(IOUtil.java:223) at sun.nio.ch.IOUtil.read(IOUtil.java:197) at sun.nio.ch.SocketChannelImpl.read(SocketChannelImpl.java:379) at org.jenkinsci.remoting.nio.FifoBuffer$Pointer.receive(FifoBuffer.java:136) at
[JIRA] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb I've added a bit of debug to list connected devices (if any) whilst waiting for the emulator to boot up. android-emulator-2.12-SNAPSHOT.hpi Can someone who can reproduce this problem please test this and post the build console output. The code used to produce this build can be found at https://github.com/jenkinsci/android-emulator-plugin/pull/39 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Richard Mortimer commented on JENKINS-24272 jnlp slaves fail to reconnect when master is restarted https://github.com/jenkinsci/remoting/pull/25 https://github.com/jenkinsci/jenkins/pull/1372 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Richard Mortimer commented on JENKINS-24272 jnlp slaves fail to reconnect when master is restarted I propose to add a onReconnect() callback to the EngineListener interface in remoting. That gets called after the slave has detected that the master has recovered. The master then hooks into the new onReconnect() callback instead of onDisconnect() and restarts the slave at that point. I've tested this on my setup with both linux and windows slaves using old slave.jar; new slave.jar with old onDisconnect() restart callback and new slave.jar with new onReconnect() restart callback. All combinations interacted properly and the fix was observed to reconnect properly with the onReconnect() hooked up in 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Richard Mortimer started work on JENKINS-24272 jnlp slaves fail to reconnect when master is restarted Change By: Richard Mortimer (15/Aug/14 7:33 PM) Status: Open InProgress 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Richard Mortimer assigned JENKINS-24272 to Richard Mortimer jnlp slaves fail to reconnect when master is restarted Change By: Richard Mortimer (15/Aug/14 7:33 PM) Assignee: KohsukeKawaguchi RichardMortimer 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] [core] (JENKINS-19055) In case of connection loss, slave JVM should restart itself if it can
Richard Mortimer commented on JENKINS-19055 In case of connection loss, slave JVM should restart itself if it can This fix is causing jnlp slaves to fail to reconnect when the master is restarted. See JENKINS-24272 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] [core] (JENKINS-24272) jnlp slaves fail to reconnect when master is restarted
Richard Mortimer created JENKINS-24272 jnlp slaves fail to reconnect when master is restarted Issue Type: Bug Assignee: Kohsuke Kawaguchi Components: core Created: 14/Aug/14 10:04 AM Description: I have noticed that whenever I restart my Jenkins master my jnlp slaves are not reconnecting and require a manual slave restart to bring them back online. I've traced this back to the changes to fix JENKINS-19055. Specifically those changes cause the slave JVM to be restarted when the master disconnects. Prior to this change the remoting engine would wait for the server to restart before attempting to reconnect to the master. With the change it immediately tries to connect to the master and get a connection error because the master is restarting. This causes the slave to immediately terminate. Jenkins 1.575 gives the following slave log output when restarting the master Aug 12, 2014 3:55:15 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated Aug 12, 2014 3:55:15 PM jenkins.slaves.restarter.JnlpSlaveRestarterInstaller$2$1 onDisconnect INFO: Restarting slave via jenkins.slaves.restarter.UnixSlaveRestarter@32a9f661 Aug 12, 2014 3:55:17 PM hudson.remoting.jnlp.Main createEngine INFO: Setting up slave: bishop Aug 12, 2014 3:55:17 PM hudson.remoting.jnlp.Main$CuiListener init INFO: Jenkins agent is running in headless mode. Aug 12, 2014 3:55:17 PM hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among [http://jenkins.example/] Aug 12, 2014 3:55:18 PM hudson.remoting.jnlp.Main$CuiListener error SEVERE: http://jenkins.example/tcpSlaveAgentListener/ is invalid: 503 Service Temporarily Unavailable java.lang.Exception: http://jenkins.example/tcpSlaveAgentListener/ is invalid: 503 Service Temporarily Unavailable at hudson.remoting.Engine.run(Engine.java:213) Notice the "jenkins.slaves.restarter.JnlpSlaveRestarterInstaller" onDisconnect log message that performs a slave restart. Prior to JENKINS-19055 being integrated the slave called waitForServerToBack() repeatedly until the master came back online. For example 25-Mar-2014 10:52:16 hudson.remoting.jnlp.Main$CuiListener status INFO: Terminated 25-Mar-2014 10:52:26 hudson.remoting.Engine waitForServerToBack INFO: Failed to connect to the master. Will retry again java.net.ConnectException: Connection refused at java.net.PlainSocketImpl.socketConnect(Native Method) at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:327) at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:193) at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:180) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:385) at java.net.Socket.connect(Socket.java:546) at sun.net.NetworkClient.doConnect(NetworkClient.java:173) at sun.net.www.http.HttpClient.openServer(HttpClient.java:409) at sun.net.www.http.HttpClient.openServer(HttpClient.java:530) at sun.net.www.http.HttpClient.init(HttpClient.java:240) at sun.net.www.http.HttpClient.New(HttpClient.java:321) at sun.net.www.http.HttpClient.New(HttpClient.java:338) at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:935) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:876) at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:801) at hudson.remoting.Engine.waitForServerToBack(Engine.java:371) at hudson.remoting.Engine.run(Engine.java:278) ... 25-Mar-2014 10:54:11 hudson.remoting.Engine waitForServerToBack INFO: Master isn't ready to talk to us. Will retry again: response code=503 25-Mar-2014 10:54:21 hudson.remoting.Engine waitForServerToBack INFO: Master isn't ready to talk to us. Will retry again: response code=503 25-Mar-2014 10:54:31 hudson.remoting.jnlp.Main$CuiListener status INFO: Locating server among http://jenkins.example/ 25-Mar-2014 10:54:31 hudson.remoting.jnlp.Main$CuiListener status INFO: Connecting to
[JIRA] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb @Guillaume your log looks to be showing a different error. The "error: device offline" message stops appearing meaning that the emulator is correctly connected to adb. You did not show the latter part of the log where the build actually failed but it could be that the failure was due to the emulator being slow to boot and android-emulator-plugin just gave up waiting. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Are you able to try following android emulator plugin build It will be interesting to see if it helps your situation. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Can you post the log please. If the correct build was installed the order of some messages should have changed. I would just like to confirm that before investigating further. Does the error always seem to happen for you? Knowing that will be a good data point! 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] [android-emulator] (JENKINS-23736) Emulator plugin can not run emulator if user is not logged on to desktop
Richard Mortimer commented on JENKINS-23736 Emulator plugin can not run emulator if user is not logged on to desktop I don't have a OS X system to test on but it looks like ADB is trying to connect to the graphical desktop but this is presumably failing because the Jenkins slave does not have access to the desktop. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Can you open a new JIRA ticket for the non-snapshots issue. The debug from that clearly shows that the adb server is failing to start properly. I think that particular issue needs investigating first. The other failing to connect to adb is likely to be related but lets address them separately first. We also need to find a way to make it more reproducible on other systems. Does it always happen on your system? Or does it sometime work? Could it be system load related? Is your slave heavily loaded? What OS type/version are you using? 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb I just upgraded to 2.11.1 from my private build of the plugin. 2.11.1 failed to connect to the emulator in the way described above. I haven't investigated the reason why yet but it was definitely working in the private build. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer assigned JENKINS-11952 to Richard Mortimer Emulator occasionally hangs indefinitely on startup, unable to connect adb Change By: Richard Mortimer (09/Jul/14 4:00 PM) Assignee: ChristopherOrr RichardMortimer 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb I have only managed to reproduce the issue once on 2.11.1 and never on any other version of the emulator. Thus I do not think that the problem is specific to 2.11.1. From my knowledge about how emulator startup works I suspect that the emulator is starting up faster than the ADB server. Then when the emulators gets to the stage where it tries to register with the ADB server it fails because ADB is not ready to accept connections on the ADB socket. The relevant emulator code in external/qemu/android/qemu-setup.c has a comment that says /* send a simple message to the ADB host server to tell it we just started. * it should be listening on port 5037. if we can't reach it, don't bother */ Looking at the android-emulator-plugin code in AndroidEmulator.java the ADB process is started but the code only waits for it to complete after the emulator has been started. It would seem sensible to not start the emulator until ADB has been confirmed to have started. I have a patch that I am testing now and will submit a pull request later today. 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] [android-emulator] (JENKINS-11952) Emulator occasionally hangs indefinitely on startup, unable to connect adb
Richard Mortimer commented on JENKINS-11952 Emulator occasionally hangs indefinitely on startup, unable to connect adb Pull request submitted at https://github.com/jenkinsci/android-emulator-plugin/pull/38 Testing appreciated using the android-emulator-plugin.hpi image from the autobuilder at https://jenkins.ci.cloudbees.com/job/plugins/job/android-a-plugin/65/org.jenkins-ci.plugins$android-emulator/ 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] [core] (JENKINS-15156) Builds disappear from build history after completion
Richard Mortimer resolved JENKINS-15156 as Fixed Builds disappear from build history after completion Many issues could have similar symptoms. The root cause of the original issue has been fixed. Please log any further occurrences in a new issue. Change By: Richard Mortimer (23/May/14 2:10 PM) Status: Reopened Resolved Resolution: Fixed 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] [core] (JENKINS-15156) Builds disappear from build history after completion
Richard Mortimer commented on JENKINS-15156 Builds disappear from build history after completion I suggest logging that as a new issue and linking it to this one. Irrespective of whether or not it is related the comments trail/information is just too big/complex on this issue. 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] [core] (JENKINS-15156) Builds disappear from build history after completion
Richard Mortimer commented on JENKINS-15156 Builds disappear from build history after completion Please open a new JIRA issue to track the Gerrit Trigger issue. This is definitely a different issue to the original bug although it has similar symptoms. It gets too confusing if we overload one issue that has been resolved for over a year. 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] [core] (JENKINS-20858) Images missing from Jenkins UI
Richard Mortimer commented on JENKINS-20858 Images missing from Jenkins UI The fix went into 1.558. I have that running here and it is now unpacking the WAR file into /var/cache/jenkins/war as per the --webroot setting. 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] [core] (JENKINS-22442) Jetty exploding war to /tmp is a bad idea
Richard Mortimer commented on JENKINS-22442 Jetty exploding war to /tmp is a bad idea The fix went into 1.558. I have that running here and it is now unpacking the WAR file into /var/cache/jenkins/war as per the --webroot setting. 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] [core] (JENKINS-17526) Broken CSS when reloading Jenkins after a time of inactivity
Richard Mortimer commented on JENKINS-17526 Broken CSS when reloading Jenkins after a time of inactivity The fix for JENKINS-22442 restores the previous behaviour and 1.558 now honours the --webroot commandline argument again. 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] [core] (JENKINS-20682) Starting Jenkins with defined --webroot or JETTY_HOME not working.
Richard Mortimer resolved JENKINS-20682 as Duplicate Starting Jenkins with defined --webroot or JETTY_HOME not working. Duplicate of JENKINS-22442 Change By: Richard Mortimer (11/Apr/14 1:45 PM) Status: Open Resolved Resolution: Duplicate 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] [android-emulator] (JENKINS-22334) plugin thinks emulator always crashes using sdk 22.6.1
Richard Mortimer commented on JENKINS-22334 plugin thinks emulator always crashes using sdk 22.6.1 I have a feeling this is related to the fix to make sure that the Android emulator accepts 5 digit port numbers. https://android-review.googlesource.com/#/c/79532/ That would cause both a localhost and emulator instance to be registered with ADB. This is related to the fix for JENKINS-12821 which only uses the emulator instance. I did experiment with my proposed fix for JENKINS-12821 https://github.com/jenkinsci/android-emulator-plugin/pull/27 to make it register a localhost instance in ADB but that seemed to think that the emulator had crashed. I didn't get chance to explore that further yet. 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] [core] (JENKINS-20682) Starting Jenkins with defined --webroot or JETTY_HOME not working.
Richard Mortimer commented on JENKINS-20682 Starting Jenkins with defined --webroot or JETTY_HOME not working. See JENKINS-22442 It should fix the issue reported here. 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] [core] (JENKINS-20858) Images missing from Jenkins UI
Richard Mortimer commented on JENKINS-20858 Images missing from Jenkins UI See JENKINS-22442 It should fix the issue reported here without requiring the tmpdir hack in 1.555 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] [core] (JENKINS-17526) Broken CSS when reloading Jenkins after a time of inactivity
Richard Mortimer commented on JENKINS-17526 Broken CSS when reloading Jenkins after a time of inactivity See JENKINS-22442 It should fix the issue reported here. 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] [core] (JENKINS-17526) Broken CSS when reloading Jenkins after a time of inactivity
Richard Mortimer commented on JENKINS-17526 Broken CSS when reloading Jenkins after a time of inactivity I think that this is the same issue as JENKINS-20682. I added some notes regarding how that might be fixed but don't have the time at the moment to delve into the workings of winstone.jar to make a production ready fix. 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] [core] (JENKINS-20682) Starting Jenkins with defined --webroot or JETTY_HOME not working.
Richard Mortimer
commented on JENKINS-20682
Starting Jenkins with defined --webroot or JETTY_HOME not working.
The Jetty documentation shows how the location of the temporary directories can be controlled
http://www.eclipse.org/jetty/documentation/current/ref-temporary-directories.html
I just did a quick experiment by adding a call to WebAppContext#setTempDirectory() in HostConfiguration#create()
https://github.com/jenkinsci/winstone/blob/master/src/java/winstone/HostConfiguration.java
i.e.
wac.setTempDirectory(new File("/var/cache/jenkins/temp"));
When jenkins.war was built with a version of winstone.jar containing that the Jetty temporary directory moved away from /tmp into /var/cache/jenkins/temp
That isn't a full solution to the problem because it needs hooking into the --webroot argument to jenkins.
There are other issues relating to how it works with multiple webapps (they should not share the same temp directory) and the usage of the temp folder is slightly different (it uses a /webapp subdirectory) to the old native winstone behaviour.
I don't know the internal plumbing of Winstone/Jenkins well enough to make a stab at a full fix for this.
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] [core] (JENKINS-20682) Starting Jenkins with defined --webroot or JETTY_HOME not working.
Richard Mortimer updated JENKINS-20682 Starting Jenkins with defined --webroot or JETTY_HOME not working. Change By: Richard Mortimer (05/Feb/14 3:37 PM) Priority: Major Critical 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] [core] (JENKINS-20682) Starting Jenkins with defined --webroot or JETTY_HOME not working.
Richard Mortimer assigned JENKINS-20682 to Kohsuke Kawaguchi Starting Jenkins with defined --webroot or JETTY_HOME not working. Assigning to Kohsuke (who made the change to Jetty) for comment. I believe that this is an unintended consequence of moving to Jetty. Note that this is not just a case of the war being exploded into TEMPDIR but I have observed that it continues to serve images etc from the old --webroot location based on the last non-Jetty version of Jenkins (see JENKINS-20858 ). The symptoms are quite subtle and at a minimum this bug needs resolving before the next LTS release. Change By: Richard Mortimer (07/Jan/14 12:00 PM) Assignee: KohsukeKawaguchi 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] [android-emulator] (JENKINS-20819) Be able to set emulator ports statically not randomly
Richard Mortimer commented on JENKINS-20819 Be able to set emulator ports statically not randomly You may find that the fix for JENKINS-12821 will help you. That moves the adb port to be a 4 digit number (outside of the 5554-5585 range) and that means that the devices attach themselves and are addressed as emulator-. I believe that ddmlib uses environment variable ANDROID_ADB_SERVER_PORT and indeed with that fix builds using maven find the emulator without any additional assistance. The fix has not been merged yet but is in pull request https://github.com/jenkinsci/android-emulator-plugin/pull/27 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] [android-emulator] (JENKINS-12821) android.device
Richard Mortimer commented on JENKINS-12821 android.device For reference the fix to workaround the broken AOSP functionality is at https://github.com/jenkinsci/android-emulator-plugin/pull/27 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] [core] (JENKINS-20407) Installation of Debian package v1.538 fails: chown: cannot access `/var/run/jenkins': No such file or directory
Richard Mortimer commented on JENKINS-20407 Installation of Debian package v1.538 fails: chown: cannot access `/var/run/jenkins: No such file or directory The changelog shows that this is fixed in 1.540. http://jenkins-ci.org/changelog 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] [core] (JENKINS-20407) Installation of Debian package v1.538 fails: chown: cannot access `/var/run/jenkins': No such file or directory
Richard Mortimer updated JENKINS-20407 Installation of Debian package v1.538 fails: chown: cannot access `/var/run/jenkins: No such file or directory This is likely going to affect all users using Debian/Ubuntu packaging so needs resolving ASAP. Change By: Richard Mortimer (09/Nov/13 11:58 AM) Priority: Major Critical 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] [core] (JENKINS-20407) Installation of Debian package v1.538 fails: chown: cannot access `/var/run/jenkins': No such file or directory
Richard Mortimer assigned JENKINS-20407 to Peter Eisentraut Installation of Debian package v1.538 fails: chown: cannot access `/var/run/jenkins: No such file or directory Pull request 956 removes /var/run/jenkins from debian/dirs but there are still references to the directory in other locations. https://github.com/jenkinsci/jenkins/pull/956 Change By: Richard Mortimer (09/Nov/13 11:55 AM) Assignee: PeterEisentraut 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] [port-allocator] (JENKINS-18908) Port Allocator v1.6 serializes all builds
Richard Mortimer resolved JENKINS-18908 as Duplicate Port Allocator v1.6 serializes all builds Duplicate of JENKINS-18786 Change By: Richard Mortimer (24/Jul/13 10:17 PM) Status: Open Resolved Resolution: Duplicate 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] [port-allocator] (JENKINS-18908) Port Allocator v1.6 serializes all builds
Richard Mortimer assigned JENKINS-18908 to Richard Mortimer Port Allocator v1.6 serializes all builds Change By: Richard Mortimer (24/Jul/13 10:16 PM) Assignee: ramapulavarthi RichardMortimer 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] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Richard Mortimer commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently I have released 1.7 with my simple fix (pull/3) that has already been tested. Will release Peter's full fix including Pooled ports once Peter has had chance to test. 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] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Richard Mortimer assigned JENKINS-18786 to Peter Wilcsinszky Port allocation blocks jobs from executing concurrently Assign to Peter (who fixed JENKINS-11255) to check that he has no objections to the proposed fix for this issue. I don't think the fix will break pooled ports but you never know! Change By: Richard Mortimer (22/Jul/13 4:58 PM) Assignee: RichardMortimer PeterWilcsinszky 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] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Richard Mortimer commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently Thanks for testing. 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] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Richard Mortimer commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently Thanks for the information. That all makes sense. I've reproduced the problem here and have a proposed fix. https://github.com/jenkinsci/port-allocator-plugin/pull/3 Can you test the auto-build version with that pull requested included and confirm that it fixes the problem for you. https://buildhive.cloudbees.com/job/jenkinsci/job/port-allocator-plugin/12/org.jenkins-ci.plugins$port-allocator/artifact/org.jenkins-ci.plugins/port-allocator/1.7-SNAPSHOT/port-allocator-1.7-SNAPSHOT.hpi 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] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Richard Mortimer assigned JENKINS-18786 to Richard Mortimer Port allocation blocks jobs from executing concurrently Change By: Richard Mortimer (18/Jul/13 7:44 PM) Assignee: ramapulavarthi RichardMortimer 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] [port-allocator] (JENKINS-18786) Port allocation blocks jobs from executing concurrently
Richard Mortimer commented on JENKINS-18786 Port allocation blocks jobs from executing concurrently This is related to the fix for JENKINS-11255. That change blocks makes the build queue rather than just block mid-build waiting for a port to become available. It is not clear to me from your report what problem this is causing you. Do the queued builds continue once the build holding the blocked port has completed? Is a build on one slave being blocked because a port is being used on another slave? Do you have a use case where you need all of the slaves to start running but then block during the build? I would help greatly if you could describe a simple test case that allows your problem to be reproduced/tested. 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] [core] (JENKINS-18671) Clock Difference broken on Manage Nodes page
Richard Mortimer commented on JENKINS-18671 Clock Difference broken on Manage Nodes page I'm seeing the same issue on 1.522. My master and slaves all run NTP and manual inspection of times shows that each slave computer is definitely within a second of the master. The web interface shows differences around 1 month 30 days ahead or behind. I have checked and confirmed that the slaves are running the slave.jar that is bundled with 1.522 but the problem still persists. I have both Linux and Windows slaves and each report the same problem. All of the Linux master/slave computers are running IcedTea6 1.12.5 (java 1.6.0_27). 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] [core] (JENKINS-18671) Clock Difference broken on Manage Nodes page
Richard Mortimer commented on JENKINS-18671 Clock Difference broken on Manage Nodes page Looks like this is caused by the fix for JENKINS-18438 https://github.com/jenkinsci/jenkins/commit/735713801b130fe247cf17bbca7b4561e41b1d13 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] [core] (JENKINS-18671) Clock Difference broken on Manage Nodes page
Richard Mortimer assigned JENKINS-18671 to Kohsuke Kawaguchi Clock Difference broken on Manage Nodes page Change By: Richard Mortimer (11/Jul/13 10:27 AM) Assignee: KohsukeKawaguchi 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] [core] (JENKINS-18671) Clock Difference broken on Manage Nodes page
Richard Mortimer assigned JENKINS-18671 to Richard Mortimer Clock Difference broken on Manage Nodes page Change By: Richard Mortimer (11/Jul/13 2:13 PM) Assignee: KohsukeKawaguchi RichardMortimer 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] [m2release] (JENKINS-17264) m2release build fails with java.lang.ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject
Richard Mortimer commented on JENKINS-17264 m2release build fails with java.lang.ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject I have just downloaded m2release-0.10.0-SNAPSHOT.hpi from the previously mentioned jenkins.ci.cloudbees.com URL The URL download page tells me that it is "Build Jenkins Maven Release Plug-in Plug-in (Apr 9, 2013 5:50:15 AM)" After uploading the .hpi and restarting Jenkins I am now running m2release 0.10.0-SNAPSHOT (private-04/09/2013 05:57-jenkins) It looks like one of your steps went wrong. 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] [m2release] (JENKINS-17264) m2release build fails with java.lang.ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject
Richard Mortimer commented on JENKINS-17264 m2release build fails with java.lang.ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject The revised m2release-plugin has not been released yet. You can download a pre-release build of it from the link in the plugin page down at the release notes section https://wiki.jenkins-ci.org/display/JENKINS/M2+Release+Plugin Specifically you need the .hpi file from https://jenkins.ci.cloudbees.com/job/plugins/job/m2release-plugin/lastStableBuild/org.jvnet.hudson.plugins.m2release$m2release/ Upload that .hpi from your jenkins plugin management centre and restart jenkins. 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] [m2release] (JENKINS-17264) m2release build fails with java.lang.ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject
Richard Mortimer resolved JENKINS-17264 as Duplicate m2release build fails with java.lang.ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject Duplicate of JENKINS-13465. Fix for that has just been integrated (not released yet though). Change By: Richard Mortimer (03/Apr/13 2:30 PM) Status: Open Resolved Resolution: Duplicate 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-17265) Builds disappearing from history
Richard Mortimer commented on JENKINS-17265 Builds disappearing from history Good detective work all! Caused by: java.lang.NullPointerException at hudson.model.AbstractBuild.getPreviousBuild(AbstractBuild.java:214) at hudson.tasks.Fingerprinter$FingerprintAction.onLoad(Fingerprinter.java:349) at hudson.model.Run.onLoad(Run.java:319) at hudson.model.RunMap.retrieve(RunMap.java:226) at hudson.model.RunMap.retrieve(RunMap.java:59) at jenkins.model.lazy.AbstractLazyLoadRunMap.load(AbstractLazyLoadRunMap.java:657) I think this relates to the following in AbstractBuild R pb = getParent().builds.search(number-1, Direction.DESC); This could be builds not being initialised as per the suggested JENKINS-16845 or it could be getParent() returning null. getParent() returns the transient project value from Run.java protected transient final JobT project; @Jose Sa can you confirm what version you saw this error on. 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-17265) Builds disappearing from history
Richard Mortimer commented on JENKINS-17265 Builds disappearing from history We need to try and identify what may/may not be causing the problems. Quite a few fixes went into 1.505 and earlier but there are obviously still a few gremlins in there. Here's a few questions that those of you seeing the problem can try to answer: are there any relevant messages in any of the Jenkins logs. Any exceptions, notices about failure to load are useful. what job types do problem occur on? maven, freestyle, other. are you running Jenkins direct from the war file or within tomcat/similar environment. what OS are your masters/slaves running? Answers to those will help to point towards the right person to fix/investigate further. 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-13465) Unable perform release: ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject on Hudson 2.2.0
Richard Mortimer commented on JENKINS-13465 Unable perform release: ClassCastException: net.sf.json.JSONNull cannot be cast to net.sf.json.JSONObject on Hudson 2.2.0 I tested Gabriel's pull request and can confirm that it fixes the problem for me. Would be nice if we could have a new plugin release. 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-16845) NullPointer in getPreviousBuild
Richard Mortimer commented on JENKINS-16845 NullPointer in getPreviousBuild I suspect that this is an instance of JENKINS-15156. The stacktrace above shows that the problem occurred at AbstractBuild.java:214 and this line references AbstractProject#builds which was not being properly re-initialized by the lazy-loading code. JENKINS-15156 is mostly fixed in 1.504 but there are still a few fixes that will be in the soon to be released 1.505. 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-17125) FingerprintAction Serializiation Bug
Richard Mortimer commented on JENKINS-17125 FingerprintAction Serializiation Bug I suspect that this is an instance of JENKINS-15156. One of the issues with that is that AbstractProject#builds was not being properly re-initialized by the lazy-loading code. JENKINS-15156 is mostly fixed in 1.504 but there are still a few fixes that will be in the soon to be released 1.505. 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-15156) Builds disappear from build history after completion
Richard Mortimer commented on JENKINS-15156 Builds disappear from build history after completion The fixes made it into the 1.502 release. Its listed in the changelog (lines 67 68) https://github.com/jenkinsci/jenkins/blob/5bca85d99253a85ae6085fc38ac592d97d8e98e6/changelog.html 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-16770) missing build title in /rssAll when build has no test result
Richard Mortimer started work on JENKINS-16770 missing build title in /rssAll when build has no test result Change By: Richard Mortimer (12/Feb/13 9:00 AM) Status: Open InProgress 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-16770) missing build title in /rssAll when build has no test result
Richard Mortimer created JENKINS-16770 missing build title in /rssAll when build has no test result Issue Type: Bug Affects Versions: current Assignee: Richard Mortimer Components: core Created: 12/Feb/13 9:00 AM Description: The title element for a build is empty in the /rssAll feed if a particular build does not have a test result but the previous build had a test result. entrytitle/link type="text/html" href="" class="code-quote">"http://jenkins.local/job/MyTestJob/19/" rel="alternate"/idtag:hudson.dev.java.net,2013:MyTestJob:2013-02-11_16-50-40/idpublished2013-02-11T16:50:40Z/publishedupdated2013-02-11T16:50:40Z/updated/entry The following stacktrace appears in jenkins.log 11-Feb-2013 17:31:11 hudson.ExpressionFactory2$JexlExpression evaluate WARNING: Caught exception evaluating: adapter.getEntryTitle(e) in /rssAll. Reason: java.lang.NullPointerException java.lang.NullPointerException at hudson.model.Run.determineDetailedUnstableSummary(Run.java:1829) at hudson.model.Run.getBuildStatusSummary(Run.java:1800) at hudson.model.Run$DefaultFeedAdapter.getEntryTitle(Run.java:2145) at hudson.model.Run$DefaultFeedAdapter.getEntryTitle(Run.java:2143) at sun.reflect.GeneratedMethodAccessor106.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.commons.jexl.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:258) at org.apache.commons.jexl.parser.ASTMethod.execute(ASTMethod.java:104) at org.apache.commons.jexl.parser.ASTReference.execute(ASTReference.java:83) at org.apache.commons.jexl.parser.ASTReference.value(ASTReference.java:57) at org.apache.commons.jexl.parser.ASTReferenceExpression.value(ASTReferenceExpression.java:51) at org.apache.commons.jexl.ExpressionImpl.evaluate(ExpressionImpl.java:80) at hudson.ExpressionFactory2$JexlExpression.evaluate(ExpressionFactory2.java:74) at org.apache.commons.jelly.parser.EscapingExpression.evaluate(EscapingExpression.java:24) at org.apache.commons.jelly.impl.ExpressionScript.run(ExpressionScript.java:66) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:124) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:124) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.tags.core.ForEachTag.doTag(ForEachTag.java:150) at org.apache.commons.jelly.impl.TagScript.run(TagScript.java:269) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.TagSupport.invokeBody(TagSupport.java:161) at org.apache.commons.jelly.impl.StaticTag.doTag(StaticTag.java:65) at org.apache.commons.jelly.impl.StaticTagScript.run(StaticTagScript.java:124) at org.apache.commons.jelly.impl.ScriptBlock.run(ScriptBlock.java:95) at org.apache.commons.jelly.tags.core.CoreTagLibrary$2.run(CoreTagLibrary.java:105) at org.kohsuke.stapler.jelly.JellyViewScript.run(JellyViewScript.java:81) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:63) at org.kohsuke.stapler.jelly.DefaultScriptInvoker.invokeScript(DefaultScriptInvoker.java:53) at org.kohsuke.stapler.jelly.JellyRequestDispatcher.forward(JellyRequestDispatcher.java:55) at hudson.model.RSS.forwardToRss(RSS.java:86) at hudson.model.View.rss(View.java:988)
[JIRA] (JENKINS-16776) surefire-reports not detected for android-maven-plugin
Richard Mortimer
created JENKINS-16776
surefire-reports not detected for android-maven-plugin
Issue Type:
Bug
Affects Versions:
current
Assignee:
Richard Mortimer
Components:
maven2
Created:
12/Feb/13 1:20 PM
Description:
Recent Jenkins releases have stopped detecting the test results produced by android-maven-plugin. This seems to be due to the refactoring done as part of the fix for JENKINS-8334.
After digging into the failure the problem is due to the reportsDir fallback code that gets executed if the mojo does not support a reportsDirectory config value.
Specifically (from SurefireArchiver.java and now TestMojo.java)
if (reportsDir == null) {
// if test mojo doesn't have such config value, still almost all
// default to target/surefire-reports
reportsDir = new File(pom.getBasedir(),
pom.getBuild().getDirectory()+File.separator+"surefire-reports");
return true;
}
The code was moved between files during the fix but was not altered. It looks like the maven-android-plugin code is now falling through to that
and exposing a bug in the old code.
Basically pom.getBuild().getDirectory() returns a full path to the build directory and not just the bare directory name (usually "target").
See http://stackoverflow.com/questions/9318935/get-project-build-directory-from-mavenproject
I have tested a proposed fix (pull request coming soon) and it works in my environment.
Environment:
Ubuntu 12.04 Jenkins 1.500
Project:
Jenkins
Priority:
Major
Reporter:
Richard Mortimer
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-16770) missing build title in /rssAll when build has no test result
Richard Mortimer commented on JENKINS-16770 missing build title in /rssAll when build has no test result See pull request https://github.com/jenkinsci/jenkins/pull/703 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-16776) surefire-reports not detected for android-maven-plugin
Richard Mortimer commented on JENKINS-16776 surefire-reports not detected for android-maven-plugin See pull request https://github.com/jenkinsci/jenkins/pull/704 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-16776) surefire-reports not detected for android-maven-plugin
Richard Mortimer
commented on JENKINS-16776
surefire-reports not detected for android-maven-plugin
I didn't look into that too deeply. I can only assume that somehow reportsDirectory is set for android-maven-plugin (although I can't find it in my copy of the source - which is about 6 months old) and hence it never fell through to the fallback mechanism.
That seems to just have been luck because the code does hardcode the output as follows in AbstractInstrumentationMojo.java
String directory = new StringBuilder()
.append(project.getBuild().getDirectory())
.append("/surefire-reports")
.toString();
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-16439) 500
Richard Mortimer resolved JENKINS-16439 as Not A Defect 500 No update in to say that this was not anything more than a full disk partition. Closing as Not a Defect. Change By: Richard Mortimer (01/Feb/13 4:30 PM) Status: Open Resolved Resolution: NotADefect 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-16439) 500
Richard Mortimer commented on JENKINS-16439 500 The cause of the exception (in the stack trace) is Caused by: java.io.IOException: No space left on device I think on of your filesystems is full. 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
[JIRA] (JENKINS-15156) Builds Disappear from Build History after Completion
Richard Mortimer
commented on JENKINS-15156
Builds Disappear from Build History after Completion
I'm wondering if this is due to the failure to re-load of an individual build history in AbstractLazyLoadRunMap.java.
Specifically the search(int, Direction) method does a binary search looking for a specific build. When it finds a match it may have to load() the build record from disk. If this fails then it "silently" removes the build that it tried to load and carries on.
R r = load(idOnDisk.get(pivot), null);
if (r==null) {
// this ID isn't valid. get rid of that and retry pivot
hi--;
if (!clonedIdOnDisk) {// if we are making an edit, we need to own a copy
idOnDisk = new SortedListString(idOnDisk);
clonedIdOnDisk = true;
}
idOnDisk.remove(pivot);
continue;
}
Assuming that the failure to load is a (unknown) transient error then that would cause the build to disappear but it would be re-loaded when jenkins is restarted and the on-disk records scanned again.
I haven't seen this failure mode so I'm not able to test directly. If someone is able/willing to take a debug build of the latest jenkins I'll try to find time to add some additional debug logging to see if we can prove/disprove this theory.
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
