Try to be robust against LinkageError’s from JNA

[jglick]

An installation encountering kohsuke/akuma#15 which would normally be swallowed here nonetheless had trouble with warnings printed during Pipeline builds:

… FINE    o.j.p.w.s.d.DurableTaskStep$Execution#check: could not check /…
java.lang.UnsatisfiedLinkError: /tmp/jna-…/jna….tmp: /tmp/jna-…/jna….tmp: failed to map segment from shared object: Operation not permitted
    at java.lang.ClassLoader$NativeLibrary.load(Native Method)
    at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:2045)
    at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1928)
    at java.lang.Runtime.load0(Runtime.java:809)
    at java.lang.System.load(System.java:1094)
    at com.sun.jna.Native.loadNativeDispatchLibraryFromClasspath(Native.java:851)
    at com.sun.jna.Native.loadNativeDispatchLibrary(Native.java:826)
    at com.sun.jna.Native.<clinit>(Native.java:140)
    at com.sun.akuma.CLibrary.<clinit>(CLibrary.java:89)
    at com.sun.akuma.JavaVMArguments.resolvePID(JavaVMArguments.java:128)
    at com.sun.akuma.JavaVMArguments.ofLinux(JavaVMArguments.java:116)
    at com.sun.akuma.JavaVMArguments.of(JavaVMArguments.java:104)
    at com.sun.akuma.JavaVMArguments.current(JavaVMArguments.java:92)
    at jenkins.slaves.restarter.UnixSlaveRestarter.canWork(UnixSlaveRestarter.java:29)
    at jenkins.slaves.restarter.JnlpSlaveRestarterInstaller$2.call(JnlpSlaveRestarterInstaller.java:66)
    at jenkins.slaves.restarter.JnlpSlaveRestarterInstaller$2.call(JnlpSlaveRestarterInstaller.java:52)
Caused: java.lang.NoClassDefFoundError: com/sun/jna/Native : cannot initialize class because prior initialization attempt failed
    at org.jenkinsci.plugins.durabletask.ProcessLiveness$LibC.<clinit>(ProcessLiveness.java:117)
    at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:98)
    at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:91)
    at …
Caused: java.lang.NoClassDefFoundError: org/jenkinsci/plugins/durabletask/ProcessLiveness$LibC : cannot initialize class because prior initialization attempt failed
    at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:98)
    at org.jenkinsci.plugins.durabletask.ProcessLiveness$Liveness.call(ProcessLiveness.java:91)
    at …
    at ......remote call to JNLP4-connect connection from …(Native Method)
    at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1537)
    at hudson.remoting.UserResponse.retrieve(UserRequest.java:253)
    at hudson.remoting.Channel.call(Channel.java:822)
Caused: java.io.IOException: Remote call on JNLP4-connect connection from … failed
    at hudson.remoting.Channel.call(Channel.java:830)
    at org.jenkinsci.plugins.durabletask.ProcessLiveness._isAlive(ProcessLiveness.java:77)
    at org.jenkinsci.plugins.durabletask.ProcessLiveness.isAlive(ProcessLiveness.java:59)
    at org.jenkinsci.plugins.durabletask.BourneShellScript$ShellController.exitStatus(BourneShellScript.java:198)
    at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.check(DurableTaskStep.java:307)
    at org.jenkinsci.plugins.workflow.steps.durable_task.DurableTaskStep$Execution.run(DurableTaskStep.java:276)
    at …

Seems we were not catching LinkageErrors in ProcessLiveness correctly, and throwing them up into exitStatus.

@reviewbybees

[jglick]

diff for review

[ghost]

This pull request originates from a CloudBees employee. At CloudBees, we require that all pull requests be reviewed by other CloudBees employees before we seek to have the change accepted. If you want to learn more about our process please see this explanation.

[jglick]

BourneShellScriptTest.reboot test failure?

[jglick]

Cannot reproduce such a failure locally, and CI server is timing out.

[jglick]

I think this is caused by there being a process with PID=9999 on the test machine. Looking to see if there is some better way to figure this out.

[oleg-nenashev]

It probably collides with other ProcessLiveness and JNR PRs for Cygwin, but seems fine. 🐝

[fbelzunc]

But I would like that you explain why you know you need to check EXACTLY the port 9999. I don't get why you know that this is the PID to start looking.

[jglick]

I don't get why you know that this is the PID to start looking.

We do not. It is just a highish PID number that is unlikely to be in use on a machine which has not done much yet. But it might be, hence the second commit here. We cannot just pick a really high number since the kernel will not accept values outside some range, IIRC 16k or so.

[jglick]

@reviewbybees done

[fbelzunc]

@jglick I would like this to be merged and released :-)

[jglick]

@fbelzunc then ask @svanoort & @abayer, I am not maintaining this any more.

[jglick]

No longer necessary.