After aborting the build. The build fails with this error. So, it basically stuck at a post build step of copy artifacts

Archiving artifacts
11:29:55 ERROR: Failed to archive artifacts: Outputs**.
11:29:55 hudson.util.IOException2: Failed to extract C:\Hudson\workspace\Trunk_TS/Outputs**.
11:29:55 at hudson.FilePath.readFromTar(FilePath.java:2044)
11:29:55 at hudson.FilePath.copyRecursiveTo(FilePath.java:1956)
11:29:55 at hudson.tasks.ArtifactArchiver.perform(ArtifactArchiver.java:137)
11:29:55 at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:20)
11:29:55 at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:782)
11:29:55 at hudson.model.AbstractBuild$AbstractBuildExecution.performAllBuildSteps(AbstractBuild.java:754)
11:29:55 at hudson.model.Build$BuildExecution.post2(Build.java:183)
11:29:55 at hudson.model.AbstractBuild$AbstractBuildExecution.post(AbstractBuild.java:707)
11:29:55 at hudson.model.Run.execute(Run.java:1628)
11:29:55 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
11:29:55 at hudson.model.ResourceController.execute(ResourceController.java:88)
11:29:55 at hudson.model.Executor.run(Executor.java:246)
11:29:55 Caused by: java.io.IOException
11:29:55 at hudson.remoting.FastPipedInputStream.read(FastPipedInputStream.java:175)
11:29:55 at hudson.util.HeadBufferingStream.read(HeadBufferingStream.java:61)
11:29:55 at com.jcraft.jzlib.InflaterInputStream.fill(InflaterInputStream.java:175)
11:29:55 at com.jcraft.jzlib.InflaterInputStream.read(InflaterInputStream.java:106)
11:29:55 at org.apache.tools.tar.TarBuffer.readBlock(TarBuffer.java:257)
11:29:55 at org.apache.tools.tar.TarBuffer.readRecord(TarBuffer.java:223)
11:29:55 at hudson.org.apache.tools.tar.TarInputStream.getNextEntry(TarInputStream.java:228)
11:29:55 at hudson.FilePath.readFromTar(FilePath.java:2022)

I had the same problem after a server restart. I don't exactly know the cause, but I managed to solve it by stopping the service (on win) and removing the workspace and tools folder from the jenkins slave. After a restart of the slave everything seems to work again.

I am experiencing something similar which I posted here:
https://issues.jenkins-ci.org/browse/JENKINS-20986

I also saw these "Failed to monitor <CHANNEL_NAME> for Free Swap Space" but since this was just category "Warning" I dismissed this.
But in my case, the job also appears to hang at the "Archiving artifacts" stage and when I check the logs it says:

"SEVERE: I/O error in channel <CHANNEL_NAME>
java.io.IOException: Unexpected termination of the channel"

It appears to terminate the channel when it should collect the artifacts. Via ssh my channel automatically reconnects but after that the job will still hang at the "Archiving artifacts" stage until I manually abort it.

My older Jenkins install version 1.431 does not have this problem. There, the jobs can archive their artifact when using this exact slave. So I figure it must be a Jenkins problem itself rather than a slave problem. The slave works fine for an older jenkins install but a newer Jenkins install (version 1.509.4 LTS) has this problem.

I am running also massively into this issue rearding running VM's on demand which run slaves. More Information see attached PDF file 'MonitorFreeSwapSpace.pdf'

For me this behaviour is critical because, the slave doesn't work anymore.

Andreas: The warnings have almost surely nothing to do with your slave connection problems. Looks more like JENKINS-22932.

Daniel: Thank you for the hint. Sometimes Interpretation of log entries is difficult. I think issue 22932 is a good candidate for my Problem.

Reducing priority again.

Upgrading Jenkins to version 1.568 (including fix of JENKINS-22932) doesn't solve my problem

Andreas: Did you upgrade all the slave.jars as well? (Use VersionColumn Plugin to help you with this)

Daniel: I am starting the slave via cmd which copies the latest slave.jar from jenknins server before executing the slave.

Slave Log jar version entry:

JNLP agent connected from /192.168.6.190
<===[JENKINS REMOTING CAPACITY]===>Slave.jar version: 2.43
This is a Windows slave
Slave successfully connected and online

MANIFEST.MF Header:

Manifest-Version: 1.0
Trusted-Library: true
Application-Name: Jenkins Remoting Agent
Build-Jdk: 1.7.0_07
Built-By: kohsuke
Permissions: all-permissions
Created-By: Apache Maven
Main-Class: hudson.remoting.Launcher
Version: 2.43
Codebase: *
Archiver-Version: Plexus Archiver

Java Version:

java version "1.7.0_55"
Java(TM) SE Runtime Environment (build 1.7.0_55-b13)
Java HotSpot(TM) 64-Bit Server VM (build 24.55-b03, mixed mode)

I had a closer look into and I recongized that there was a log entry (see below) after closing the slave cmd. If my interpretation is right the slave hangs during a SVN action. I have to check if we have a SVN problem here. Maybe it was not the same problem as before.

Building remotely on 01-w7x64ENHSSw2013 (vm EN SolidWorks2013 uitest hypersnaphot Windows7 64bit) in workspace C:\JenkinsSlave\workspace\2014.2_Smoketest_EN_Simulation_SolidWorks2013
FATAL: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
hudson.remoting.RequestAbortedException: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:41)
at hudson.remoting.RequestAbortedException.wrapForRethrow(RequestAbortedException.java:34)
at hudson.remoting.Request.call(Request.java:174)
at hudson.remoting.Channel.call(Channel.java:739)
at hudson.FilePath.act(FilePath.java:909)
at hudson.FilePath.act(FilePath.java:893)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:909)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:844)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1252)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:624)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:530)
at hudson.model.Run.execute(Run.java:1732)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:234)
Caused by: hudson.remoting.RequestAbortedException: java.io.IOException: Failed to abort
at hudson.remoting.Request.abort(Request.java:299)
at hudson.remoting.Channel.terminate(Channel.java:802)
at hudson.remoting.Channel$2.terminate(Channel.java:483)
at hudson.remoting.AbstractByteArrayCommandTransport$1.terminate(AbstractByteArrayCommandTransport.java:72)
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(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)
Caused by: java.io.IOException: Failed to abort

I wonder if this is related to JENKINS-25218 where the ping thread intervenes and kills the channel (thereby breaking the livelock in Channel termination)

You could try disabling the ping thread on both sides, e.g. in the master set hudson.slaves.ChannelPinger.pingInterval=-1 and on the slave set hudson.remoting.Launcher.pingIntervalSec=-1 If my theory is correct your failure mode should turn in to the same failure mode as JENKINS-25218

Hi Stephen,

I made the changes you mentioned and got following failure, but I don't know if it is the same failure as JENKINS-25218

Building remotely on 01-w7x64DEHS-HyperCAD-S (DE uitest vm Windows7 64bit hypersnapshot) in workspace C:\JenkinsSlave\workspace\Trunk_Smoke_Sim_HCAD-S_DE
FATAL: java.io.EOFException
hudson.remoting.RequestAbortedException: java.io.EOFException
at hudson.remoting.Request.abort(Request.java:296)
at hudson.remoting.Channel.terminate(Channel.java:815)
at org.jenkinsci.remoting.nio.NioChannelHub$3.run(NioChannelHub.java:613)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(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)
at ......remote call to 01-w7x64DEHS-HyperCAD-S(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1361)
at hudson.remoting.Request.call(Request.java:171)
at hudson.remoting.Channel.call(Channel.java:752)
at hudson.FilePath.act(FilePath.java:980)
at hudson.FilePath.act(FilePath.java:969)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:897)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:833)
at hudson.scm.SCM.checkout(SCM.java:485)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1282)
at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:610)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:86)
at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:532)
at hudson.model.Run.execute(Run.java:1744)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:43)
at hudson.model.ResourceController.execute(ResourceController.java:98)
at hudson.model.Executor.run(Executor.java:374)
Caused by: java.io.EOFException
at org.jenkinsci.remoting.nio.NioChannelHub$3.run(NioChannelHub.java:613)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at hudson.remoting.SingleLaneExecutorService$1.run(SingleLaneExecutorService.java:112)
at jenkins.util.ContextResettingExecutorService$1.run(ContextResettingExecutorService.java:28)
at java.util.concurrent.Executors$RunnableAdapter.call(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)

On the basis of that stack trace, your issue is not the exact same as JENKINS-25218... though if you have not set the hudson.remoting.Launcher.pingIntervalSec=-1 property correctly on the slave (check the slave's system properties screen in Jenkins to verify) then the ping thread would still be causing the disconnect.

At present the stack trace indicates that the TCP/IP socket has been killed. If you have disabled both ping threads then that would point to a network issue between the master and slave (perhaps a firewall killing long lived sockets or a NAT gateway timeout). If you have not disabled both ping threads then the test needs repeating

isn't the -D supposed to be before the -jar but in any case, that looks like you have it the correct side of the jar file argument, so I would start looking for networking issues

I have just come across this on two types of host.

First on Illumos(Smartos)/LX zones, it occasionally reports gigantic free memory (probably a bug), after which the buld log stops updating

{{Failed to monitor Triton-455640a8f44f for Free Swap Space
java.util.concurrent.ExecutionException: java.io.IOException: Failed to parse: '18446744073709099244' out of 'MemFree: 18446744073709099244 kB'
at hudson.remoting.Channel$2.adapt(Channel.java:813)
at hudson.remoting.Channel$2.adapt(Channel.java:808)
at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:96)
at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:305)
Caused by: java.io.IOException: Failed to parse: '18446744073709099244' out of 'MemFree: 18446744073709099244 kB'
at org.jvnet.hudson.ProcMemInfo.monitor(ProcMemInfo.java:56)
at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:113)
at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:103)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:326)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
at java.util.concurrent.FutureTask.run(FutureTask.java:266)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
at ......remote call to Triton-455640a8f44f(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel$2.adapt(Channel.java:811)
... 4 more}}

I also now get this on Jenkins 2.x on windows slaves:

Failed to monitor winbuild for Free Swap Space
java.util.concurrent.ExecutionException: java.lang.UnsatisfiedLinkError: C:\Users\magnayn\AppData\Local\Temp\jna-829177819\jna2657881109746216710.dll: A dynamic link library (DLL) initialization routine failed
at hudson.remoting.Channel$2.adapt(Channel.java:813)
at hudson.remoting.Channel$2.adapt(Channel.java:808)
at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:96)
at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:305)
Caused by: java.lang.UnsatisfiedLinkError: C:\Users\magnayn\AppData\Local\Temp\jna-829177819\jna2657881109746216710.dll: A dynamic link library (DLL) initialization routine failed
at java.lang.ClassLoader$NativeLibrary.load(Native Method)
at java.lang.ClassLoader.loadLibrary0(Unknown Source)
at java.lang.ClassLoader.loadLibrary(Unknown Source)
at java.lang.Runtime.load0(Unknown Source)
at java.lang.System.load(Unknown Source)
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.jna.Pointer.<clinit>(Pointer.java:41)
at com.sun.jna.Structure.<clinit>(Structure.java:2078)
at org.jvnet.hudson.Windows.monitor(Windows.java:42)
at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:113)
at hudson.node_monitors.SwapSpaceMonitor$MonitorTask.call(SwapSpaceMonitor.java:103)
at hudson.remoting.UserRequest.perform(UserRequest.java:120)
at hudson.remoting.UserRequest.perform(UserRequest.java:48)
at hudson.remoting.Request$2.run(Request.java:332)
at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:68)
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 hudson.remoting.Engine$1$1.run(Engine.java:85)
at java.lang.Thread.run(Unknown Source)
at ......remote call to winbuild(Native Method)
at hudson.remoting.Channel.attachCallSiteStackTrace(Channel.java:1416)
at hudson.remoting.UserResponse.retrieve(UserRequest.java:220)
at hudson.remoting.Channel$2.adapt(Channel.java:811)
... 4 more

Failure seems to kill the channel

Ping failed. Terminating the channel winbuild.
java.util.concurrent.TimeoutException: Ping started at 1462866895203 hasn't completed by 1462867135208
at hudson.remoting.PingThread.ping(PingThread.java:126)
at hudson.remoting.PingThread.run(PingThread.java:85)

I don't know why the space monitor re-throws the error as an exception - it might be an idea to swallow it and log.

Experiencing this same issue with a slave that is used on demand.

jenkins.err.zip

Please someone help still experiencing this.

JENKINS-48309 may be a culprit. TimeoutException may happen before the timeout time really passes, and the stacktraces from xtaylor21x and the issue reporter point to the affected code.

Nov 02, 2016 2:51:12 PM hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor monitor
WARNING: Failed to monitor PRW8-32-A for Free Swap Space
java.util.concurrent.TimeoutException
	at hudson.remoting.Request$1.get(Request.java:279)
	at hudson.remoting.Request$1.get(Request.java:207)
	at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
	at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:96)
	at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:305)

I also just started experiencing this situation under 2.222.3 under Java 1.8_242 under z/OS USS. This was after increasing the Node SSH timeout to something large. The Node log is showing:

ERROR: Failed to monitor for Response Time
java.util.concurrent.TimeoutException
{{ at hudson.remoting.Request$1.get(Request.java:316)}}
{{ at hudson.remoting.Request$1.get(Request.java:240)}}
{{ at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)}}
{{ at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitorDetailed(AbstractAsyncNodeMonitorDescriptor.java:114)}}
{{ at hudson.node_monitors.ResponseTimeMonitor$1.monitor(ResponseTimeMonitor.java:57)}}
{{ at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:306)}}
ERROR: Failed to monitor for Free Disk Space
java.util.concurrent.TimeoutException
{{ at hudson.remoting.Request$1.get(Request.java:316)}}
{{ at hudson.remoting.Request$1.get(Request.java:240)}}
{{ at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)}}
{{ at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitorDetailed(AbstractAsyncNodeMonitorDescriptor.java:114)}}
{{ at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:78)}}
{{ at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:306)}}
ERROR: Failed to monitor for Free Temp Space
java.util.concurrent.TimeoutException
{{ at hudson.remoting.Request$1.get(Request.java:316)}}
{{ at hudson.remoting.Request$1.get(Request.java:240)}}
{{ at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)}}
{{ at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitorDetailed(AbstractAsyncNodeMonitorDescriptor.java:114)}}
{{ at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:78)}}
{{ at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:306)...}}

in a loop until the SSH timeout hits, which then cancels the job by closing the connection. Are we possibly missing a dependency on the server? The server only has a straight up JDK with no additional tools (other than git and perl).

Also having this issue on Jenkins 2.229, with a Mac OS X 10.14.6 node that has java JDK 1.8.0_202 and remoting version: 4.3:

ERROR: Failed to monitor for Free Swap Space
java.util.concurrent.TimeoutException
	at hudson.remoting.Request$1.get(Request.java:316)
	at hudson.remoting.Request$1.get(Request.java:240)
	at hudson.remoting.FutureAdapter.get(FutureAdapter.java:59)
	at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitorDetailed(AbstractAsyncNodeMonitorDescriptor.java:114)
	at hudson.node_monitors.AbstractAsyncNodeMonitorDescriptor.monitor(AbstractAsyncNodeMonitorDescriptor.java:78)
	at hudson.node_monitors.AbstractNodeMonitorDescriptor$Record.run(AbstractNodeMonitorDescriptor.java:306)

I disabled Swap Space monitoring but that made no difference. The node cannot be recovered once it gets in that state unless the machine is manually rebooted. This happens multiple times a week.

I met this issue today. Just for your reference.

Issue:

The slave hint "server reject to connect" and look through the node log, it shows "Failed to monitor for Free Temp Space/Free Disk Space/Free Temporary Space  etc.

Reason :

Someone changed the Slave name from lower letter to capital ones.

Resolution:

Re-download jnlp and run it in slave, that is succeed.

I've also seen this.  A system trace for remoting shows: 

 
Sep 26, 2020 8:13:36 AM FINER hudson.remoting.ChannelBuilder
Sending capability preamble: Capability{Multi-ClassLoader RPC, Pipe throttling, Mimic Exception, Prefetch, Greedy RemoteInputStream, Proxy writer 2.35, Chunked encoding, ProxyException fallback}
Sep 26, 2020 8:13:36 AM FINER hudson.remoting.ChannelBuilder
Awaiting mode preamble...

-------------------------------

As a work around, kill the OMVS process on MVS and delete the remoting jar on the host and restart the agent.  Also check that your agent's JVM startup options include -Dfile.encoding=UTF-8  

Lastly, there is a global node monitoring  page to suspend monitoring.