Re: [bug] git clone command leaves orphaned ssh process

From: Jeff King <peff@peff.net>
Date: Sep 25, 2023, 12:29 UTC
Message-ID: <20230925122921.GA2118294@coredump.intra.peff.net>
In-Reply-To: <CAN47KsUDS0om6r6WwRZHLHdETHE+Lu=bj1skG1cAwvzEUaF81Q@mail.gmail.com>

On Sun, Sep 24, 2023 at 01:25:08PM +0300, Max Amelchenko wrote:

Show 8 quoted lines

> Thanks,
> Just wanted to clarify something. This will not be handled by AWS (we
> had a support ticket re. that case), since they do not interfere with
> the running processes on its infrastructure, and if there is a
> problematic process causing this overflowing in orphaned processes, it
> needs to be handled by that process.
> The question is, doesn't Git want to ensure a clean exit in all cases?
> This is a clear example of a non-clean exit.

Git does ensure a clean exit if we run the clone process to completion. In your case we hit a fatal error midway through and are aborting. At that point we do not care what the exit code of ssh is.

We _could_ set up a signal/atexit handler combo to call waitpid(), but we would just be throwing away the result code. And that is a catch-all I would rather see done by PID 1 than by git. It can serve all processes, not just git. And it can do so more robustly, since git may be killed without a chance to run cleanup code (e.g., signal 9).

-Peff