From: Ken Brown <kbrown@cornell.edu>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: Re: ssh-agent doesn't die
Date: Fri, 04 Oct 2019 14:27:00 -0000 [thread overview]
Message-ID: <801bca17-2c61-bb6a-f02c-c4912232d9c5@cornell.edu> (raw)
In-Reply-To: <185c5774-dd8b-5488-b818-4cec5a24bf2d@cornell.edu>
On 9/29/2019 4:05 PM, Ken Brown wrote:
> On 9/27/2019 10:12 AM, Ken Brown wrote:
>> On 9/27/2019 9:37 AM, Norton Allen wrote:
>>> On 9/26/2019 10:50 PM, Ken Brown wrote:
>>>>
>>>>> As a simple test example, consider:
>>>>>
>>>>> /bin/ssh-agent /bin/sleep 10
>>>>>
>>>>> While the sleep is still running, ps shows:
>>>>>
>>>>> PID PPID PGID WINPID TTY UID STIME COMMAND
>>>>> 1694 1693 1694 1576 ? 22534 00:01:10
>>>>> /usr/bin/ssh-agent
>>>>> 1653 1 1653 11740 cons1 22534 00:00:37 /usr/bin/bash
>>>>> 1693 1653 1693 1552 cons1 22534 00:01:10 /usr/bin/sleep
>>>>>
>>>>> One oddity is that ssh-agent is listed as a subprocess of sleep
>>>> ...but this isn't a bug. ssh-agent forks, and then the parent execs the command.
>>>
>>> With the salient difference presumably being that the exec is done in the parent
>>> instead of the child as usual?
>>
>> Yes. The idea is that 'ssh-agent command' should be more-or-less equivalent to
>> running 'command', with ssh-agent running as a subprocess.
>>
>> The ssh-agent subprocess periodically checks to see if its parent is still
>> alive, and it exits when the parent has died. Someone should figure out why
>> this is not working on Cygwin.
>
> As an aid to someone who might want to debug this (probably Corinna when she
> returns), I've created a test program agent.c (attached) that simulates the
> relevant part of ssh-agent:
>
> 1. It forks a subprocess that periodically checks to see if its parent has died,
> and then exits.
>
> 2. The parent execs "/usr/bin/sleep 1".
>
> As with ssh-agent, the subprocess never detects that the parent has died, and so
> it never exits.
>
> Running this program under strace shows the following error in the pinfo
> constructor:
>
> pinfo::pinfo: couldn't duplicate parent rd_proc_pipe handle 0x1BC for forked
> child 1666 after exec, Win32 error 5
>
> [Win32 error 5 is ERROR_ACCESS_DENIED.]
It seems that the pinfo constructor failure happens in
cygheap_exec_info::reattach_children(). The latter is preceded by the following
comment:
/* Reattach non-reaped subprocesses passed in from the cygwin process
which previously operated under this pid. FIXME: Is there a race here
if the process exits during cygwin's exec handoff? */
I tried running my test program under gdb with a breakpoint at
reattach_children, and the breakpoint was never hit. That gives an affirmative
answer to the question in the FIXME.
As a result, the exec'd program never becomes aware that it has a subprocess, so
it exits without resetting the subprocess's ppid to 1.
Is there someone out there familiar enough with Cygwin's exec to suggest a fix?
It would be a nice gift to Corinna to get this fixed before her return.
Ken
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
next prev parent reply other threads:[~2019-10-04 14:27 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-09-27 0:34 Tim Adye
2019-09-27 2:43 ` Norton Allen
2019-09-27 5:38 ` Ken Brown
2019-09-27 14:12 ` Norton Allen
2019-09-27 14:27 ` Ken Brown
2019-09-27 15:09 ` Vanda Vodkamilkevich
2019-09-27 23:18 ` Ken Brown
2019-09-27 23:59 ` Norton Allen
[not found] ` <185c5774-dd8b-5488-b818-4cec5a24bf2d@cornell.edu>
2019-10-04 14:27 ` Ken Brown [this message]
2019-10-04 20:13 ` Ken Brown
2019-11-03 19:01 ` Corinna Vinschen
2019-11-04 11:49 ` Tim Adye
2019-11-04 14:17 ` Corinna Vinschen
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=801bca17-2c61-bb6a-f02c-c4912232d9c5@cornell.edu \
--to=kbrown@cornell.edu \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).