Ble.sh: ssh options freeze bash

[rlanore]

ble version: 0.4.0-devel3+0506df2
Bash version: 5.1.4(1)-release, x86_64-pc-linux-gnu

Completely freeze when add some ssh options:

ssh -v # everything stop

Into tmux nothing is displayed. into alacritty i can show this

rlanore@px-rla:[~] on ☁️  (us-east-1) ✦1
[] 🠶 ssh -vble/contrib/fzf: failed to find "fzf" base directory

This appear only on ssh command

[rlanore]

i tried to initialize fzf and ble.sh as follows

# Setup fzf
_ble_contrib_fzf_base=/home/rlanore/Documents/git/github/fzf/bin/fzf
ble-import -d contrib/fzf-completion
ble-import -d contrib/fzf-key-bindings

But i get

rlanore@px-rla:[~] on ☁️  (us-east-1) ✦1
[✦1 ] 🠶 ble/contrib/fzf-initialize: "fzf" not found.
ble/function#advice: __fzf_generic_path_completion is not a function.
ble/function#advice: _fzf_complete is not a function.
ble/function#advice: _fzf_complete_kill is not a function.
ble/contrib/fzf-initialize: "fzf" not found.
rlanore@px-rla:[~] on ☁️  (us-east-1) hub/fzf/bin/fzf/shell/key-bindings.bash: Not a directory
[] 🠶

[rlanore]

I fix my fzf path to directory path and no binary. But ssh freeze always

[akinomyoga]

Thank you for the report! This should be related to the interaction with bash-completion or fzf-completion.

Frozen ssh

To separate the problem, I have a question:

Question 1 What happens when you press TAB after ssh -v in a plain Bash (without ble.sh).

fzf initialization errors

ble/contrib/fzf: failed to find "fzf" base directory

This error message typically happens when fzf is not found in the directories specified by PATH environment variable even though fzf-completion settings are loaded.

i tried to initialize fzf and ble.sh as follows

Can you specify the fzf directory path for _ble_contrib_fzf_base?

 # Setup fzf
-_ble_contrib_fzf_base=/home/rlanore/Documents/git/github/fzf/bin/fzf
+_ble_contrib_fzf_base=/home/rlanore/Documents/git/github/fzf
 ble-import -d contrib/fzf-completion
 ble-import -d contrib/fzf-key-bindings

I fix my fzf path to directory path and no binary. But ssh freeze always

OK. I now added a note on the description of _ble_contrib_fzf_base: https://github.com/akinomyoga/blesh-contrib/commit/62101190730225b5e22ffcbd87d76ab2e59663a5.

[rlanore]

hi thanks for reply.
I have spawn a new shell and ble-detach to reply to question and i get this:
I will NOT in tmux for now.

rlanore@px-rla:[~] on ☁️  (us-east-1)
[] 🠶 ssh -v
::1             192.168.16.     192.168.18.     xxx          xxx            xxx            ff02::1         ip6-allnodes    ip6-localhost   localhost
10.99.          192.168.17.     192.168.19.     xx          xx            xxxxx    ff02::2         ip6-allrouters  ip6-loopback    px-rla
rlanore@px-rla:[~] on ☁️  (us-east-1)
[] 🠶 ssh -v

xxxx: is for anonymous some suggestion

[rlanore]

Notice that my known_hosts file contain some entry with ecdsa-sha2-nistp256 and another with ssh-rsa

[rlanore]

Entry encoded by ecdsa-sha2-nistp256 is not suggested by fzf.

[akinomyoga]

OK, it seems it works with the plain Bash, so there are some differences in the environment where bash-completion is called. I tried the same in my environment but everything works fine in my environment.

Can you provide me the result of the following command?

$ complete -p ssh
$ declare -p BASH_COMPLETION_VERSINFO

Also, does the same problem occur with ble-0.3?

Edit: I would like to check your fzf version as well.

$ fzf --version

Notice that my known_hosts file contain some entry with ecdsa-sha2-nistp256 and another with ssh-rsa

Edit: My .ssh/known_hosts also contains both types of entries.

[murase@chatoyancy 1 ble.sh]$ awk 'd[$2];END{for(k in d)print k;}' ~/.ssh/known_hosts
ecdsa-sha2-nistp256
ssh-rsa

[rlanore]

The result of command:

```
rlanore@px-rla:[~] on ☁️ (us-east-1)
[] 🠶 complete -p ssh
complete -o bashdefault -o default -F _fzf_host_completion ssh
rlanore@px-rla:[~] on ☁️ (us-east-1)
[] 🠶 declare -p BASH_COMPLETION_VERSINFO
declare -a BASH_COMPLETION_VERSINFO=([0]="2" [1]="11")
rlanore@px-rla:[~] on ☁️ (us-east-1)
[] 🠶 fzf --version
0.26.0 (34fe5ab)

Do you get suggestion on ecdsa-sha2-nistp256 keys ?

[akinomyoga]

Do you get suggestion on ecdsa-sha2-nistp256 keys ?

Actually, I get nothinig from _fzf_host_completion (fzf-completion). I get hostnames of both types of keys from _ssh (bash-completion). Maybe first I need to check why _fzf_host_completion doesn't work in my environment.

[akinomyoga]

I've updated the fzf from 0.21.1 to 0.26.0. Now _fzf_host_completion generates hostnames of both types of keys (including ecdsa-sha2-nistp256).

[rlanore]

Seems to be working with 0.3 version.

rlanore@px-rla:~/.../github/ble.sh$ complete -p ssh
complete -F _fzf_host_completion ssh
rlanore@px-rla:~/.../github/ble.sh$ declare -p BASH_COMPLETION_VERSINFO
declare -a BASH_COMPLETION_VERSINFO=([0]="2" [1]="11")
rlanore@px-rla:~/.../github/ble.sh$ fzf --version
0.26.0 (34fe5ab)
rlanore@px-rla:~/.../github/ble.sh$ echo $BLE_VERSION
0.3.3+7fa584c
rlanore@px-rla:~/.../github/ble.sh$ ssh -v 192.168.18.
::1            10.99.         192.168.16.    192.168.17.    192.168.18.    192.168.19.    xxx    ff02::1        ff02::2
ip6-allnodes   ip6-allrouters ip6-localhost  ip6-loopback   localhost      px-rla

[akinomyoga]

Sorry, may I ask about the version of ble-0.3?

$ echo $BLE_VERSION

[rlanore]

I don't understand i have switch to v0.3-master. run make and source out ble.sh.
I get this ble version. What do you mean by ble-0.3 ?

rlanore@px-rla:~/.../github/fzf$ echo $BLE_VERSION
0.3.3+7fa584c

[akinomyoga]

OK, thank you for the version information! I meant 0.3.* by ble-0.3, but I just wanted to confirm which specific version of 0.3.* you have tried.

Oh, sorry. I just noticed that you have already included the result of $BLE_VERSION in the first reply. It's just my oversight. Thank you

[riblo]

FYI

ble version: 0.4.0-devel3+0506df2
Bash version: 5.0.18(1)-release (x86_64-pc-linux-gnu)

ssh -v works fine but the same "freeze" issue happened to me typing:
➤ netstat -p or ➤ netstat -a and not if I type: netstat --all

I tried before to downgrade to v0.3.3 and everything works fine, so re-tried the latest version and ... I was surprised that the issue is gone ¯\_(ツ)_/¯

PS: during the freeze, I found in other shell some "man -w netstat" child processes in loop...

[akinomyoga]

Thank you for the information!

PS: during the freeze, I found in other shell some "man -w netstat" child processes in loop...

Ah, OK. Maybe I got where is the problem. Maybe this is unrelated to fzf. Do you load the completion settings of fzf? Would the issue also occur without fzf?

[riblo]

Maybe this is unrelated to fzf

Yes, atm I don't use fzf

Do you load the completion settings of fzf? Would the issue also occur without fzf?

Exactly, issue happened without fzf

[akinomyoga]

OK, thank you for the information. I'm a bit busy recently, but I try to find the time to dig into this issue. Thank you!

[akinomyoga]

@riblo @rlanore Today I have looked at the related codes, but unfortunately, I still don't have an idea what happened to your environments.

I found in other shell some "man -w netstat" child processes in loop...

@riblo I'm interested in the above situation in more detail. In particular, what does "in loop" mean? Does it mean that many processes of man -w netstat were running at the same time? Or does it mean one process of man -w netstat has occupied one core of CPU? Or does it mean another man -w netstat would have been launched every time you killed the process?

@rlanore Do you still have the same problem. Also, if you have time, could you check if the hang happens when fzf bash settings are not loaded in order to check your issue and @riblo's are the same issue or not?

Thank you for your help.

[riblo]

Or does it mean one process of man -w netstat has occupied one core of CPU?

Exactly this, I used "in loop" expression but what l noticed was: one cpu stuck at 100%.
This was the behavior: during the freeze, in htop I noticed one core 100% on the process man -w netstat => child of terminator -> bash -> (ble.sh)

[akinomyoga]

@riblo OK! Thank you for the clarification! Indeed ble.sh calls man -w netstat 2>/dev/null but expects it to terminate soon with the output of the path to the man page source. Hmm, but ble.sh just simply calls man -w netstat 2>/dev/null, so I'm not sure what causes man to freeze. It is probably a bug of man -w.

Did you experience the same phenomena again since then? If it happens often, I would think about implementing the timeout of man.

[rlanore]

Hi, sorry for late response i have been too busy. But now it's ok.
I did a try without fzf and the problem still append.
In an ohter shell i have checked for a man -w process and it appear and disappear a lot.

[rlanore]

Very strange problem with man command. I quick bash loop with thousand iteraration. All man command working no freeze.

[rlanore]

I make a mistake:

when i have disabled fzf i will just reload bash and the probem persist. But into a completely new shell they are no problem with ssh and ble.sh without fzf.

[rlanore]

I think that i found my problem with ssh.
I have define an alias for ssh like

alias ssh="TERM=xterm ssh"

when disable it' works

but i have need this because my workstation is not on xterm but a lot of server will.

also when searching to debug with strace i see that they are a lot of ble.sh cache with empty file.

[rlanore]

Fix my alias problem with a wrapper script ssh. Thanks for your time

[rlanore]

Sorry reopened for @riblo problem

[akinomyoga]

@rlanore Thank you for new information!

In an ohter shell i have checked for a man -w process and it appear and disappear a lot.

OK, maybe it's not just a single process of man -w, but ble.sh might be executing many man -w in an infinite loop.

when i have disabled fzf i will just reload bash and the probem persist. But into a completely new shell they are no problem with ssh and ble.sh without fzf.

Then, maybe some interference between fzf completion settings and the option completer built in ble.sh.

alias ssh="TERM=xterm ssh"

Oh, I think this is an important information. It seems I still cannot reproduce the problem soon, but I will take time to investigate what it will cause.

also when searching to debug with strace i see that they are a lot of ble.sh cache with empty file.

I think this is also a good hint.

Thank you!

[akinomyoga]

@rlanore @riblo Yesterday, I could reproduce the problem, so I added a fix 0efcb65. Thank you!

[akinomyoga]

I think now the problem has been fixed, so let me close this issue. If there is still a problem, please feel free to reopen this issue and describe the problem. Thank you again for reporting the problem and also providing me with detailed information!