summaryrefslogtreecommitdiff
path: root/Remote
diff options
context:
space:
mode:
authorGravatar Joey Hess <joey@kitenet.net>2014-08-03 16:35:35 -0400
committerGravatar Joey Hess <joey@kitenet.net>2014-08-03 16:53:29 -0400
commitb01ed93441e81a9dbd17c9974fe683101f879f2a (patch)
tree4733d6f0ca8968d17b103b13212d675782403b4c /Remote
parent6a1b296ef5d97cccebc1ee9d793a8e874e434373 (diff)
move ugly rsync zombie workaround
This reaping of any processes came to cause me problems when redoing the rsync special remote -- a gpg process that was running gets waited on and the place that then checks its return code fails. I cannot reproduce any zombies when using the rsync special remote. But I still can when using a normal git remote, accessed over ssh. There is 1 zombie per file downloaded without this horrible hack enabled. So, move the hack to only be used in that case.
Diffstat (limited to 'Remote')
-rw-r--r--Remote/Helper/Ssh.hs9
1 files changed, 8 insertions, 1 deletions
diff --git a/Remote/Helper/Ssh.hs b/Remote/Helper/Ssh.hs
index 05a98865f..e0199dca3 100644
--- a/Remote/Helper/Ssh.hs
+++ b/Remote/Helper/Ssh.hs
@@ -102,13 +102,20 @@ dropKey r key = onRemote r (boolSystem, False) "dropkey"
rsyncHelper :: Maybe MeterUpdate -> [CommandParam] -> Annex Bool
rsyncHelper callback params = do
showOutput -- make way for progress bar
- ifM (liftIO $ (maybe rsync rsyncProgress callback) params)
+ ok <- ifM (liftIO $ (maybe rsync rsyncProgress callback) params)
( return True
, do
showLongNote "rsync failed -- run git annex again to resume file transfer"
return False
)
+ {- For an unknown reason, this causes rsync to run a second
+ - ssh process, which it neglects to wait on.
+ - Reap the resulting zombie. -}
+ liftIO reapZombies
+
+ return ok
+
{- Generates rsync parameters that ssh to the remote and asks it
- to either receive or send the key's content. -}
rsyncParamsRemote :: Bool -> Remote -> Direction -> Key -> FilePath -> AssociatedFile -> Annex [CommandParam]