diff options
author | Joey Hess <joey@kitenet.net> | 2014-08-03 16:35:35 -0400 |
---|---|---|
committer | Joey Hess <joey@kitenet.net> | 2014-08-03 16:53:29 -0400 |
commit | b01ed93441e81a9dbd17c9974fe683101f879f2a (patch) | |
tree | 4733d6f0ca8968d17b103b13212d675782403b4c /Remote | |
parent | 6a1b296ef5d97cccebc1ee9d793a8e874e434373 (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.hs | 9 |
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] |