This is a discussion on Re: openssh-agent polling - openssh ; David Leonard wrote: > Damien Miller wrote: >> On Wed, 12 Sep 2007, Alan Jenkins wrote: >>> This may be a stupid question - but why does ssh-agent fork off >>> a child and then exec the subcommand in the ...
David Leonard wrote:
> Damien Miller wrote:
>> On Wed, 12 Sep 2007, Alan Jenkins wrote:
>>> This may be a stupid question - but why does ssh-agent fork off
>>> a child and then exec the subcommand in the *parent* process?
>>> It forces the agent in the child process to poll the parent, so
>>> it can exit when the parent finishes. If the agent was the
>>> parent process, it could use wait() instead. I'm sure there's
>>> some reason.
>>> It'd be nice to take ssh-agent off the list of polling
>>> processes you get with powertop, however far down it is.
> ssh-agent starts its command in the parent process probably so that
> you can get something useful from $! returned in your startup
Surely that's fixable - wait() gives you the terminated child's exit code.
> and to avoid the situation where ssh-agent could get an untrappable
> signal and leaves the underlying command running.
Which way round do you mean this? Are we trying to avoid leaving the
underlying command running if ssh-agent is killed, or do we want it to
carry on running independently? It sounds like you meant the
subcommand should be killed if ssh-agent is, but my understanding of
the current behaviour is that the subcommand keeps on running.
If the aim is to keep the subcommand running, I guess we're stuck with
polling. If I've got my un*x right, it's not possible to wait() on a
process unless it would get killed if you terminate.
> I can't see a clean, portable way of getting rid of the poll. On
> linux, maybe you use inotify or /proc or something??
Apparently inotify doesn't tell you when /proc directories go away
:-(. There is a netlink message that gets sent for accounting
purposes, but you have to configure it in, so I don't know how widely
available it would be, and IIRC it's not very well-suited because you
get messages for all processes, not just one.
openssh-unix-dev mailing list