Re: Bug report: orphaned pack-objects after killing upload-pack on [

Subsystems: the rest

2 messages, 2 authors, 2020-11-26 · open the first message on its own page

Re: Bug report: orphaned pack-objects after killing upload-pack on [

From: Junio C Hamano <hidden>
Date: 2020-11-25 21:42:29

Jeff King [off-list ref] writes:
So I think it is still a good idea to do, and what I wrote earlier is
as good a we can do.

René, do you want to wrap up your similar patch for the fetch side?
In the meantime, I may queue this on 'seen' but it cannot move
forward without a signoff.

Thanks.
--- >8 ------ >8 ------ >8 ------ >8 ------ >8 ---
From: René Scharfe <redacted>
Date: Fri, 20 Nov 2020 19:52:45 +0100
Subject: [PATCH] upload-pack: kill pack-objects helper on signal or exit

We spawn an external pack-objects process to actually send objects
to the remote side. If we are killed by a signal during this
process, the pack-objects will hang around as a zombie.  We should
take it down when we go down.
---
 upload-pack.c | 1 +
 1 file changed, 1 insertion(+)
diff --git a/upload-pack.c b/upload-pack.c
index 3b858eb457..d4f7192d04 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -321,6 +321,7 @@ static void create_pack_file(struct upload_pack_data *pack_data,
 	pack_objects.in = -1;
 	pack_objects.out = -1;
 	pack_objects.err = -1;
+	pack_objects.clean_on_exit = 1;
 
 	if (start_command(&pack_objects))
 		die("git upload-pack: unable to fork git-pack-objects");
-- 
2.29.2-538-g65d51b1459

Re: Bug report: orphaned pack-objects after killing upload-pack on [

From: Jeff King <hidden>
Date: 2020-11-26 00:53:30

On Wed, Nov 25, 2020 at 01:42:24PM -0800, Junio C Hamano wrote:
quoted hunk
In the meantime, I may queue this on 'seen' but it cannot move
forward without a signoff.

Thanks.
--- >8 ------ >8 ------ >8 ------ >8 ------ >8 ---
From: René Scharfe <redacted>
Date: Fri, 20 Nov 2020 19:52:45 +0100
Subject: [PATCH] upload-pack: kill pack-objects helper on signal or exit

We spawn an external pack-objects process to actually send objects
to the remote side. If we are killed by a signal during this
process, the pack-objects will hang around as a zombie.  We should
take it down when we go down.
I think this is a good thing to do. I'd probably avoid the word "zombie"
here, though. The orphaned pack-objects does not become a zombie process
in the traditional Unix sense of the word, waiting to be reaped by a
parent which is not paying attention. Instead it is still running but
doing work for a caller that will never read the result.

So maybe:

  We spawn an external pack-objects process to actually send objects to
  the remote side. If we are killed by a signal during this process,
  then pack-objects may continue to run. As soon as it starts producing
  output for the pack, it will see a failure writing to upload-pack and
  exit itself. But before then, it may do significant work traversing
  the object graph, compressing deltas, etc, which will all be
  pointless. So let's make sure to kill as soon as we know that the
  caller will not read the result.

-Peff
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help