Closed ibethune closed 8 years ago
Hi Iain,
does the use of echo "UseRoaming no" >> ~/.ssh/config
make any difference then?
Thanks, Andre.
No, I have that in my .ssh/config already (so I can log into ARCHER manually using SSH), and it was set when I hit the error above. I just wondering if SAGA/RP was doing something different internally. It might well be a red-herring.
I have the same problem as Iain does now with output as in https://gist.github.com/ashkurti/30fae1a847a8ef05414d
Can you try to run touch .hushlogin
once logged into archer?
Hmm, bugger, I am not able to reproduce it: I can run the RP archer test just fine, w/o any change of ssh settings...
Iain, if you don't mind, would you please run another test with SAGA_VERBOSE=DEBUG
, and post the (longish) output somewhere? Thanks!
ardi@eslogin001:~> touch .hushlogin ardi@eslogin001:~>
Andre: does saga use -q
? Those two together should turn off all verbosity.
@marksantcroos: I don't have hushlogin set... :/
@andre-merzky thats because you are behind a dialup link
@marksantcroos: no, no -q used...
What would be the difference of the dialup?
@ashkurti And then retry again.
@marksantcroos: no, no -q used...
Why not? :)
My archer ssh config entry looks like:
host archer login.archer.ac.uk
hostname login.archer.ac.uk
user marksant
LogLevel QUIET
With this and hushlogin I can get rid of most prompt detection errors.
Gah, now it's working... If Ardita can confim it's now working as well, we can close. Some temporary glitch...
@marksantcroos: no, no -q used... Why not? :)
Let's focus ;)
My job is in the queue and before running it again I did launch from ARCHER the "touch .hushlogin" command.
Let's focus ;)
I dont understand that comment.
Gah, now it's working... If Ardita can confim it's now working as well, we can close. Some temporary glitch...
Its a timing issue, likely not a glitch.
So you still want to see a recreate with SAGA_VERBOSE=Debug ?
@ibethune : For a failing run, yes, please!
@marksantcroos : -q
might make sense, but it should also work without, so I'd rather first try to find why it hangs before cleaning up with -q
... Am I missing something?
@ibethune - So did it work fine without any errors similar to the ones that @vivek-bala was having yesterday?
No I get problems with coco. I'm going to file a separate ticket for that. It's to do with which modules are loaded.
This one will be closed later if I don't get a recreate of the original problem.
My job is still in the queue ... I do expect it to behave like yours though, not to have any problems with the shell but to have problems with the coco-installation. I tried running the coco workflow on stampede that also uses the 0-25 version and everything works just fine on stampede.
I did not get any problems with the shell access now on ARCHER, but more at a coco installation level as explained in Issue #236
I think we could close this issue unless somebody is willing to investigate the weird behaviour happening with ARCHER for the shell login access.
Closing, unless it re-occurs
If I try running one of the example workflows (here coco-amber) I get the following error:
I have the following versions installed (basically everything from the latest releases on pip):
The only thing I know which might be related to this is that due to a recent security issue in OpenSSH (https://access.redhat.com/articles/2123781) ARCHER will now reject all incoming SSH connections which have the 'roaming' feature enabled in the client. The manual fix is to edit the .ssh/config:
I don't know if this is the root cause of the problem or not, but worth investigating!