Note it may be possible to have the ssh execution code always run with verbose output, but capture the output instead of directly logging it, and have some way of knowing when the SSH verbose junk ends and the real command output begins. Always log the real command output, and selectively log the verbose SSH output only if we get a certain kind of failure, indicating SSH errors.
That'd take some research but it'd probably be ideal, though possibly not worth the complexity at this time. Steve On Wed, Jan 20, 2010 at 10:01 AM, John Admanski <[email protected]> wrote: > On Tue, Jan 19, 2010 at 9:17 PM, Eric Li(李咏竹) <[email protected]> wrote: >> Agree, in a failure scenario, run test in verbose mode and you will get the >> ssh command. >> Then you would have to copy paste the ssh command and retry. >> If the "-q" patch was pushed in, you had to remove the -q option in order to >> see what warn/error messages are from the ssh command. >> >> Its not a perfect working scenario. I am ok with it, but I respect some >> other people might not be ok with it. > > I don't like the idea of automatically re-running a command that > actually does something; for example if the command is launching the > autotest client and the connection gets killed for some reason or > another, we don't necessarily want to be running that command again. > > The failures mentioned here so far all talk about failures which occur > when establishing the connection, but it's also possible to get ssh > errors (i.e. exit status 255 errors) after the remote command has been > launched; so it's quite possible we could actually be running the > remote command multiple times. > > It would probably be safer to run something like "true" in verbose > mode. If the problem is a non-transient one involving the > establishment of the connection then you would still get the logs you > need. > > -- John > >> Martin, >> What is your opinion? >> Eric >> On Tue, Jan 19, 2010 at 3:56 PM, Lucas Meneghel Rodrigues <[email protected]> >> wrote: >>> >>> On Tue, Jan 19, 2010 at 3:06 PM, Eric Li(李咏竹) <[email protected]> wrote: >>> > To be frank, I have the same concern too. Lets wait and see if any other >>> > people could raise some thing more concrete. >>> >>> Usually when ssh fails, we end up having to debug what is wrong >>> running the command with increased verbosity, so maybe it would be a >>> good idea to re-run the base command with increased verbosity in case >>> it fails once. The problems more likely to happen are the following: >>> >>> 1) SSH key is incorrectly setup on the client machine (there's no key >>> on the client, .ssh directory permissions are wrong, selinux contexts >>> are incorrect) so that's a downright error, not warning >>> 2) Client machine dies and SSH connection times out, or 'no route to >>> host' message, which is also an error. >>> >>> So in both cases I believe an actual error message will be generated. >>> Need to test though. If test shows up that the main problem scenarios >>> we're interested in are covered with error messages, then I see little >>> harm on accepting the patch. We can allways do a retry with normal (or >>> increased) verbosity if something goes wrong, like I already >>> mentioned. >>> >>> > Eric. >>> > On Tue, Jan 19, 2010 at 9:02 AM, John Admanski <[email protected]> >>> > wrote: >>> >> >>> >> On Tue, Jan 19, 2010 at 8:59 AM, Eric Li(李咏竹) <[email protected]> >>> >> wrote: >>> >> > Dear autotest community, >>> >> > This is a follow up patch to abstract_ssh.py, which used to supress >>> >> > the >>> >> > message "Warning: Permanently added 'XX.XX.XX.XX' (RSA) to the list >>> >> > of >>> >> > known hosts." Since now the known_host file is pointing to /dev/null, >>> >> > it >>> >> > will popup multiple times during one test run. Quite annoy. >>> >> > I believe this change should have very little impact to existing >>> >> > autotest >>> >> > users. >>> >> >>> >> Doesn't this run some risk of suppressing other potentially useful >>> >> warnings? I'm not saying I have a specific problem in mind, it's just >>> >> a general concern I have. >>> >> >>> >> -- John >>> >> >>> >> > Eric >>> >> > On Fri, Jan 15, 2010 at 10:15 AM, Martin Bligh <[email protected]> >>> >> > wrote: >>> >> >> >>> >> >> applied >>> >> >> >>> >> >> On Fri, Jan 15, 2010 at 10:00 AM, Eric Li(李咏竹) <[email protected]> >>> >> >> wrote: >>> >> >> > Thanks. Anyone could help me to apply this patch? >>> >> >> > >>> >> >> > On Fri, Jan 15, 2010 at 9:42 AM, Gregory P. Smith <[email protected]> >>> >> >> > wrote: >>> >> >> >> >>> >> >> >> LGTM >>> >> >> >> >>> >> >> >> On Fri, Jan 15, 2010 at 8:50 AM, Eric Li(李咏竹) <[email protected]> >>> >> >> >> wrote: >>> >> >> >> > Seems people prefer the hard coded solutions. So I am proposing >>> >> >> >> > a >>> >> >> >> > simpler >>> >> >> >> > patch. >>> >> >> >> > Please review. >>> >> >> >> > Thanks. >>> >> >> >> > >>> >> >> >> > On Fri, Jan 15, 2010 at 7:22 AM, John Admanski >>> >> >> >> > <[email protected]> >>> >> >> >> > wrote: >>> >> >> >> >> >>> >> >> >> >> 2010/1/15 Lucas Meneghel Rodrigues <[email protected]>: >>> >> >> >> >> > On Thu, Jan 14, 2010 at 10:34 PM, Martin Bligh >>> >> >> >> >> > <[email protected]> >>> >> >> >> >> > wrote: >>> >> >> >> >> >> John, Steve - this looks generally correct to me. If this >>> >> >> >> >> >> is >>> >> >> >> >> >> going >>> >> >> >> >> >> to >>> >> >> >> >> >> break you guys, >>> >> >> >> >> >> I guess we can make it configurable (but default on), but >>> >> >> >> >> >> don't >>> >> >> >> >> >> think >>> >> >> >> >> >> it'll cause >>> >> >> >> >> >> problems? >>> >> >> >> >> > >>> >> >> >> >> > -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null >>> >> >> >> >> > seems >>> >> >> >> >> > very >>> >> >> >> >> > reasonable flags to use since we are dealing with test >>> >> >> >> >> > machines, >>> >> >> >> >> > and >>> >> >> >> >> > those get reinstalled frequently. Every time I have to >>> >> >> >> >> > reinstall a >>> >> >> >> >> > client machine, I have to cleam entries on known_hosts (and >>> >> >> >> >> > I >>> >> >> >> >> > confess >>> >> >> >> >> > I am still doing it manually, wich is a PITA). >>> >> >> >> >> > >>> >> >> >> >> > I'd just add them to the ssh flags, but indeed need to check >>> >> >> >> >> > with >>> >> >> >> >> > John >>> >> >> >> >> > and Steve if this is going to have side effects. I see none. >>> >> >> >> >> > >>> >> >> >> >> >>> >> >> >> >> These options are fine with me. >>> >> >> >> >> >>> >> >> >> >> -- John >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > -- >>> >> >> >> > Eric Li >>> >> >> >> > 李咏竹 >>> >> >> >> > Google Kirkland >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > >>> >> >> >> > _______________________________________________ >>> >> >> >> > Autotest mailing list >>> >> >> >> > [email protected] >>> >> >> >> > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >>> >> >> >> > >>> >> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > -- >>> >> >> > Eric Li >>> >> >> > 李咏竹 >>> >> >> > Google Kirkland >>> >> >> > >>> >> >> > >>> >> >> > >>> >> >> > _______________________________________________ >>> >> >> > Autotest mailing list >>> >> >> > [email protected] >>> >> >> > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >>> >> >> > >>> >> >> > >>> >> > >>> >> > >>> >> > >>> >> > -- >>> >> > Eric Li >>> >> > 李咏竹 >>> >> > Google Kirkland >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > Autotest mailing list >>> >> > [email protected] >>> >> > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >>> >> > >>> >> > >>> > >>> > >>> > >>> > -- >>> > Eric Li >>> > 李咏竹 >>> > Google Kirkland >>> > >>> > >>> > >>> > _______________________________________________ >>> > Autotest mailing list >>> > [email protected] >>> > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest >>> > >>> > >>> >>> >>> >>> -- >>> Lucas >> >> >> >> -- >> Eric Li >> 李咏竹 >> Google Kirkland >> >> >> > _______________________________________________ > Autotest mailing list > [email protected] > http://test.kernel.org/cgi-bin/mailman/listinfo/autotest > _______________________________________________ Autotest mailing list [email protected] http://test.kernel.org/cgi-bin/mailman/listinfo/autotest
