On 04/30/2018 08:33 AM, Daniel P. Berrangé wrote: > The behaviour whereby virt-manager forks into the background was added > way back in: > > commit 99c92b9471a6a55859307071aa4a0e712991f158 > Author: Daniel P. Berrange <berrange@xxxxxxxxxx> > Date: Mon Sep 10 20:10:20 2007 -0400 > > Refactor startup to drop controlling TTY, avoiding annoying SSH prompts > > While it achieves its stated goal, this is quite a big hammer to use > with unpleasant side effects. Most end users will launch virt-manager > from the desktop which will fork the app into the background already. > Even when running from the command line, modern desktop environments > will have things setup up so that all SSH prompts are intercepted and > presented via a graphical window. Forking into the background causes > extra pain for developers as warnings that would otherwise appear on > stderr get lost e.g. > > commit 24a8b66b35c92bed919a4a6beb7c7fb80e85b3b2 > Author: Daniel P. Berrangé <berrange@xxxxxxxxxx> > Date: Wed Apr 4 14:35:40 2018 +0100 > > avoid referencing ConnectError if it is None > > Currently it throws an exception at startup which is hidden unless you > run with --no-fork > > The limited benefit of forking is not worth the pain it causes, so > just start "normally" as any other GTK app would. I'd love to be able to drop this, but consider this case: install virt-manager to /usr/share with this patch, then run it from gnome-shell and try to connect to an ssh host that requires a password. ssh will print the password prompt to stdout which the user doesn't see, and the connection attempt just hangs until whenever ssh times out. This is the crux of the problem and I don't know any way around it. There's no way to force ssh to launch askpass without forking+setsid. if we wanted to drop passwordauth entirely for ssh and mandate keys or other auth, we can extend libvirt to allow passing -o PasswordAuthentication=no to ssh, but then it'd still be years before we could drop the --no-fork behavior. Maybe the libssh conn options can help here but there would still be trickyness adapting to it I'm sure For VNC/SPICE console where virt-manager launches ssh directly we have more control and more options, but it's all kind of moot if the conn open still requires forking. Any ideas? Thanks, Cole _______________________________________________ virt-tools-list mailing list virt-tools-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/virt-tools-list
