summaryrefslogtreecommitdiff
path: root/Utility
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 /Utility
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 'Utility')
-rw-r--r--Utility/Rsync.hs10
1 files changed, 2 insertions, 8 deletions
diff --git a/Utility/Rsync.hs b/Utility/Rsync.hs
index 60381264e..d0a89b2b0 100644
--- a/Utility/Rsync.hs
+++ b/Utility/Rsync.hs
@@ -66,14 +66,8 @@ rsyncParamsFixup = map fixup
- The params must enable rsync's --progress mode for this to work.
-}
rsyncProgress :: MeterUpdate -> [CommandParam] -> IO Bool
-rsyncProgress meterupdate params = do
- r <- catchBoolIO $
- withHandle StdoutHandle createProcessSuccess p (feedprogress 0 [])
- {- For an unknown reason, piping rsync's output like this does
- - causes it to run a second ssh process, which it neglects to wait
- - on. Reap the resulting zombie. -}
- reapZombies
- return r
+rsyncProgress meterupdate params = catchBoolIO $
+ withHandle StdoutHandle createProcessSuccess p (feedprogress 0 [])
where
p = proc "rsync" (toCommand $ rsyncParamsFixup params)
feedprogress prev buf h = do