FEATURE: -f -f - fork after successful open of fwd port/display/agent

[Dan Astoorian]

On Mon, 04 Feb 2002 09:52:25 EST, Nicolas Williams writes:
> 
> Do you have any wrappers that add -f? I think I can code wrappers to be
> smart enough about this, so I'm not concerned.

You're approaching the question from the wrong direction.  Can *you*
guarantee that nobody else has wrappers that add -f?  If someone has, do
you think this feature justifies breaking their existing deployment when
they upgrade OpenSSH, when this could trivially have been avoided?

I'm not arguing because I have wrappers that your feature will break;
I'm arguing because I don't want OpenSSH's design to grow unnecessary
tumours.

And for what it's worth, yes, I do have a wrapper which adds -f: my
users use it to launch X applications.  I could also add code to my
wrapper to filter out multiple -f's.  I shouldn't have to.

> > but the idea of '-f -f' having a *qualitatively* different meaning than
> > '-f' is a little unsettling.  You're not using "-f -f" to mean "-f, only
> > more so"; it appears as if you just didn't want to use up another letter
> > for a option with nearly identical semantics.
> 
> No, I'm making "-f -f" mean "like -f, but a bit later".

And that's a substantial, qualitative difference.  You're changing the
interpretation of the return code, and in the case where the command
doesn't happen to use forwarding features, you're preventing the
backgrounding from taking place at all.  Consider the difference in
behaviour for:

    ssh -f -f remotehost 'sleep 600; date >> /var/run/foo' && echo "ok"

with and without your patch.

> > Think harder :-)
> 
> Sure. Have you any suggestions?

No, but then, I don't approve of the feature.

> I agree on principle. But there are exceptions to rules of thumb and I
> think this is one of them. Have you understood the feature?

I haven't read the patch, but yes, I understand what you're trying to do
with this feature, and I still think the benefits of this feature are
outweighed by its poor fit into the existing design (which could make
the feature difficult to maintain in the future).

> > (A cleaner design would be for -f to make ssh background itself only
> > after the exec() of the command on the server side had succeeded, so
> 
> No, this does not guarantee that by the time ssh exits the X11 display
> has been opened by the remote command or that the remote command has
> exited. This is what I'm after.

You can't guarantee that the X11 display has been opened successfully
even if the forwarding has been established.  The X11 display could
refuse the connection at the X protocol level, or the X11 app could
abort between opening the X11 server and mapping its first window, for
any of a number of reasons.

In any case, it's not ssh's job to make sure the application operates as
intended.

> People use "ssh -f ..." as an approximation of "ssh -f -f ..." for
> launching X apps. Visual feedback tells them whether or not something
> went wrong.

Or stderr tells them.

> But suppose you're writing a GUI app so users can start X apps with a
> click of a mouse. How do you check for errors in starting the remote
> apps? [...]

Watch the stdout/stderr of the ssh process, and don't use -f.  If you
have an application for which you have a particular need to verify that
it started up correctly, make the application output a positive
acknowledgement to stdout or stderr, and have the launcher watch for it.

The original purpose of -f was to let ssh stay in the foreground long
enough to prompt for passphrases; if you're doing it from a window
manager, there's usually no downside to just putting the whole process
in the background.

-- 
Dan Astoorian               People shouldn't think that it's better to have
Sysadmin, CSLab             loved and lost than never loved at all.  It's
djast at cs.toronto.edu        not, it's better to have loved and won.  All
www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican