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

From: René Scharfe <l.s.r@web.de>
Date: Nov 26, 2020, 20:04 UTC
Message-ID: <bd2c4577-4c8c-851c-6045-ba4b306ca612@web.de>
In-Reply-To: <xmqqo8jllyhc.fsf@gitster.c.googlers.com>

Am 26.11.20 um 02:04 schrieb Junio C Hamano:

Show 18 quoted lines

> Jeff King <peff@peff.net> writes:
>
>> On Wed, Nov 25, 2020 at 01:42:24PM -0800, Junio C Hamano wrote:
>>
>>> In the meantime, I may queue this on 'seen' but it cannot move
>>> forward without a signoff.
>>>  ...
>>   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.
>
> Thanks, that reads well.
>

The patch is trivial, you don't need my sign-off. You could record Peff as its author, as he contributed the most to the version in seen.

Before I could submit that one (or something similar) formally, I'd need to understand what's happening here a lot better and witness the effect of the patch.

I understand that the main benefit of stopping the child upon termination of the parent is to avoid using CPU cycles on a heavy task whose results will just go to waste. But wouldn't the orphaned child then become a zombie? Init would reap it eventually, but are there perhaps init-less deployments (containerized daemon?) where such zombies could pile up?

For a test, winning the race condition should be easy if we cheat by letting the child loop forever. But I struggle even with the most basic task: Making upload-pack invoked by clone call pack-objects. (Feeling a bit silly.)

René