Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

verdi computer option to switch off login shell #4271

Merged
merged 3 commits into from Jul 23, 2020

Conversation

unkcpz
Copy link
Member

@unkcpz unkcpz commented Jul 16, 2020

Issue closing #2978 happened to me when connecting to TianHe-2 . The messages output to the login shell was set in file /etc/profile. I make a rough fix and let it set in verdi computer configuration ssh .

EDIT:
local transport plugin should also configurable with on/off login shell. As well as gotocomputer_command of all transport plugins. To avoid repeating define bash_command and repeating gotocomputer command string, encapsulating them in Tranport class.

@unkcpz unkcpz requested a review from ltalirz July 16, 2020 09:46
@codecov
Copy link

codecov bot commented Jul 16, 2020

Codecov Report

Merging #4271 into develop will increase coverage by 0.05%.
The diff coverage is 100.00%.

Impacted file tree graph

@@             Coverage Diff             @@
##           develop    #4271      +/-   ##
===========================================
+ Coverage    79.19%   79.24%   +0.05%     
===========================================
  Files          468      468              
  Lines        34476    34488      +12     
===========================================
+ Hits         27301    27325      +24     
+ Misses        7175     7163      -12     
Flag Coverage Δ
#django 71.16% <100.00%> (+0.04%) ⬆️
#sqlalchemy 71.99% <100.00%> (+0.05%) ⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
aiida/transports/plugins/local.py 81.29% <100.00%> (+0.82%) ⬆️
aiida/transports/plugins/ssh.py 77.76% <100.00%> (+1.38%) ⬆️
aiida/transports/transport.py 65.30% <100.00%> (+1.49%) ⬆️
aiida/engine/daemon/client.py 73.57% <0.00%> (+1.15%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update ef1caa0...d30fa6f. Read the comment docs.

Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for this PR, @unkcpz !

I was originally responsible for switching to using the login shell, the reason is explained in #1502, but if there are systems that force outputs on login shells that a user cannot suppress, then I guess it makes sense to be able to not use a login shell.
I think making this configurable is potentially quite useful.

Some minor change requests.

@giovannipizzi Do you agree with making this configurable?
It does mean another "variable" one has to keep in mind when debugging things...

aiida/transports/plugins/ssh.py Outdated Show resolved Hide resolved
aiida/transports/plugins/ssh.py Outdated Show resolved Hide resolved
Copy link
Member Author

@unkcpz unkcpz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @ltalirz

aiida/transports/plugins/ssh.py Outdated Show resolved Hide resolved
ltalirz
ltalirz previously approved these changes Jul 17, 2020
Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

thanks @unkcpz , for me this is good to go.

would be good to have a brief feedback from @giovannipizzi or @sphuber as well.

Copy link
Contributor

@sphuber sphuber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @unkcpz . I have gone through the issue and the original commit that added the -l flag by default, and based on the information provided there this seems reasonable, especially since the default remains untouched. But I have to say that I don't have an enormous amount of experience with the difference in interactive and non-interactive shells. I have just two minor suggestions for help strings, but won't force an update. Would be good if @giovannipizzi can maybe give a final sign off

'default': True,
'switch': True,
'prompt': 'Use login shell when executing command',
'help': ' Avoiding a login shell can help suppress spurious text output'
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
'help': ' Avoiding a login shell can help suppress spurious text output'
'help': 'Not using a login shell can help suppress any potential spurious text output that can interfere with AiiDA executing commands, '

I guess it might not be immediately clear why suppressing spurious output is something desirable, per se.

aiida/transports/plugins/ssh.py Outdated Show resolved Hide resolved
@sphuber
Copy link
Contributor

sphuber commented Jul 17, 2020

I just realized that this can also apply to local transports, although more unlikely probably. However, for completeness, should we also add this switch there?

And finally, if I understand correctly, this would then solve #2978 ? Actually, that made me realize that probably we will want to add a small note about this new switch in this part of the documentation troubleshooting.
I would propose to add something like the following at the end of that section:

.. note::

    If, for whatever reason, the methods explained above do not work, you can also opt to change the computer configuration to not use a login shell.
    During `verdi computer configure`, set `-no-use-login-shell` or when asked to use a login shell, set it to `False`.
    This will tell AiiDA to not use a login shell when connecting, which may potentially prevent the spurious output from being printed.
    Note, however, that this may also prevent other code from being executed, such as certain environment variables being set.

@ltalirz
Copy link
Member

ltalirz commented Jul 17, 2020

It's true that this does make a difference for local transports as well.
A practical use case might be if someone wants to install AiiDA directly on the login node of the "communicative" cluster.

@unkcpz
Copy link
Member Author

unkcpz commented Jul 17, 2020

A practical use case might be if someone wants to install AiiDA directly on the login node of the "communicative" cluster.

emm.. that's true. So, put this option to setup?

@giovannipizzi
Copy link
Member

Thanks @unkcpz !
Indeed, I think it's ok to add this as an option keeping the old default - it might create other problems, but being optional it's ok. Also yes, I think it fixes #2978?

A few final points:

  • Is this automatically configurable now with verdi computer configure ssh? Can we have a test maybe?
  • Indeed, it would be good to have the same logic for local transports

@giovannipizzi
Copy link
Member

I think configure is still the right place instead of setup, but done for both backends. I had tried an attempt to simplify how the logic is managed in #3663 but it turned out to be more complex than I thought and I didn't have the time to finish that one. Maybe for now we just follow the same thing that is done for the cool down time that is defined for both plugins.

@unkcpz
Copy link
Member Author

unkcpz commented Jul 17, 2020

ok, I'll also add it to local transports.

Is this automatically configurable now with verdi computer configure ssh? Can we have a test maybe?

I add a simple test to check that autoinfo getting set with this option. @giovannipizzi

self.assertEqual(new_auth_params['use_login_shell'], True)

@unkcpz
Copy link
Member Author

unkcpz commented Jul 19, 2020

The use_login_shell option is now added to local transports.

  • To avoid repeating this setting code in two files, I add it to abstract Transport class will take effect for all transports plugins.
  • Also add test to make sure computer's auto info is set in test_local_interactive.
  • DOCS: note is added in troubleshooting part as @sphuber suggested.

@unkcpz
Copy link
Member Author

unkcpz commented Jul 19, 2020

@ltalirz I find one more place where login shell is used, here at gotocomputer_command.

""" then cd {escaped_remotedir} ; bash -l ; else echo ' ** The directory' ; """

why force user to bash login shell when they goto the specific computer, is that necessary? If there are spurious output being printed the login shell here will also cause problem.

@ltalirz
Copy link
Member

ltalirz commented Jul 19, 2020

why force user to bash login shell when they goto the specific computer, is that necessary?

I think it's the expected behavior - a user will expect the same environment variables as when connecting manually and changing to that directory, no?

If there are spurious output being printed the login shell here will also cause problem.

If it causes problems, then we may need to make it configurable here as well, but I'm not aware that AiiDA is processing the output of this command.
Can you check whether it indeed causes a problem (and why)?

@unkcpz
Copy link
Member Author

unkcpz commented Jul 19, 2020

Ah, the problem comes from the bashrc config of remote cluster, it somehow execute cd to the home directory after login. So the gotocomputer command should keep it the way it is.

For transports plugins(now we have ssh and local), add `use_login_shell`
option to allowed user to not use login shell when executing the
command.
@unkcpz
Copy link
Member Author

unkcpz commented Jul 19, 2020

@ltalirz thanks! looks better now.

@ltalirz
Copy link
Member

ltalirz commented Jul 19, 2020

Ah, the problem comes from the bashrc config of remote cluster, it somehow execute cd to the home directory after login. So the gotocomputer command should keep it the way it is.

Just so that I understand: some system-level bashrc file is being sourced only for login shells, and this breaks the gotocomputer command? Strange...

In any case, reading back through what I wrote, I think you were right after all.
It may be the "expected behavior" by default, but for people who explicitly configured AiiDA not to use a login shell, it is probably rather unexpected that AiiDA would use continue using a login shell for gotocomputer.

Given the issue you encountered, I think it's best apply the user configuration in gotocomputer as well..
Since this switching logic will now be present in three places, I suggest you encapsulate it, e.g. in a _bash_command property of the Transport.

@unkcpz
Copy link
Member Author

unkcpz commented Jul 20, 2020

I am not very familiar with login/non-login and interactive/non-interactive shell stuff, correct me if I understand it wrong.

Just so that I understand: some system-level bashrc file is being sourced only for login shells, and this breaks the gotocomputer command? Strange...

My fault for not clarifying this, not the system-level bashrc but the user's ~/.bashrc which did the cd action in the remote cluster. Using gotocomputer will always activate the ~/.bashrc no matter login shell is on or off, correct? So the problem is definitely not from AiiDA side, and can be solved by modifying the ~/.bashrc file which user always have permission to edit.

It may be the "expected behavior" by default, but for people who explicitly configured AiiDA not to use a login shell, it is probably rather unexpected that AiiDA would use continue using a login shell for gotocomputer.

Agree! If the cd action is setting in the system wide profile which users have no permission to edit, the weird cd action should be suppressed by turn off the login shell. That is when the login shell is set to false, we also expect gotocomputer use non-login shell.

`bash_command` are used in three places and set by `use_login_shell`.
Encapsulate it as attribute `_bash_command_str` of `Transport`.

gotocompyter_command have same string for local and ssh transport
plugin, Encapsulate the string as `_gotocomputer_string` in `Transport`
class.
Copy link
Member

@ltalirz ltalirz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@sphuber I'm fine with this.

One could make the _bash_command_str a @property instead of setting it in the constructor, so that it will react to changes in _use_login_shell but I don't think it's mandatory.

Thanks @unkcpz !

@sphuber sphuber self-requested a review July 23, 2020 08:24
Copy link
Contributor

@sphuber sphuber left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks a lot @unkcpz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants