| 
					
				 | 
			
			
				@@ -40,7 +40,7 @@ locations like ``/etc/environment`` or in the forced command itself (example bel 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				     ``no-port-forwarding,no-X11-forwarding,no-pty,no-agent-forwarding,no-user-rc`` 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				     in this case. 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				  
			 | 
		
	
		
			
				 | 
				 | 
			
			
				-     
			 | 
		
	
		
			
				 | 
				 | 
			
			
				+ 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				 SSH Configuration 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				 ~~~~~~~~~~~~~~~~~ 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				 ``borg serve``'s pipes (``stdin``/``stdout``/``stderr``) are connected to the ``sshd`` process on the server side. In the event that the SSH connection between ``borg serve`` and the client is disconnected or stuck abnormally (for example, due to a network outage), it can take a long time for ``sshd`` to notice the client is disconnected. In the meantime, ``sshd`` continues running, and as a result so does the ``borg serve`` process holding the lock on the repository. This can cause subsequent ``borg`` operations on the remote repository to fail with the error: ``Failed to create/acquire the lock``. 
			 | 
		
	
	
		
			
				| 
					
				 | 
			
			
				@@ -69,4 +69,3 @@ This will cause the server to send a keep alive to the client every 10 seconds. 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				 If you then run borg commands with ``--lock-wait 600``, this gives sufficient time for the borg serve processes to terminate after the SSH connection is torn down after the 300 second wait for the keepalives to fail. 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				  
			 | 
		
	
		
			
				 | 
				 | 
			
			
				 You may, of course, modify the timeout values demonstrated above to values that suit your environment and use case. 
			 | 
		
	
		
			
				 | 
				 | 
			
			
				- 
			 |