-
-
Notifications
You must be signed in to change notification settings - Fork 85
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
[WSL] ble.sh breaks on start and does not let me type in the console #426
Comments
What are the results of the following commands (you can run them inside a Bash session without ble.sh)? $ bash /path/to/ble.sh --version # <-- please replace "/path/to/ble.sh" with the path to the script file "ble.sh"
$ declare -p XDG_RUNTIME_DIR
$ id -u
$ ls -la /run/user/1000
$ mkdir -p /run/user/1000/blesh
$ ls -la /run/user/1000
$ echo t >| "/run/user/1000/blesh/$$.test.txt"
$ ls -la "/run/user/1000/blesh/$$".* |
After this, I uncommented the source command in .bashrc, and it worked for that session.
But once I executed I did this twice. It seems the blesh folder within |
Thank you for the results!
Yeah, but it should be fine. |
I see... is there anything else I could do on my end to provide more information that would be helpful? |
I'm now trying to look inside the code. I currently have no idea why it fails.
Thanks. Could you try modifying the generated --- ble.sh~^I2024-03-29 12:47:12.991139405 +0900
+++ ble.sh^I2024-03-29 12:51:04.838510981 +0900
@@ -1198,12 +1198,14 @@
fi
ble/base/.create-user-directory _ble_base_run "$tmp_dir/${USER:-$UID}@$HOSTNAME"
}
+set -x
if ! ble/base/initialize-runtime-directory; then
ble/util/print "ble.sh: failed to initialize \$_ble_base_run." 1>&2
ble/base/clear-version-variables
ble/init/clean-up 2>/dev/null # set -x 対策 #D0930
return 1
fi
+set +x
: >| "$_ble_base_run/$$.load"
function ble/base/clean-up-runtime-directory {
local opts=$1 failglob= noglob= (Edit: Sorry I initially pasted the diff of the wrong part (for |
Okay so upon modifying the
Once I restart the VM, this is what I get:
I'm actually not that knowledgeable about programming so I hope despite my naivete this is useful anyway. |
Thanks. As far as I see those results, the directory seems to be created. How about this change in the generated --- ble.sh~^I2024-03-29 12:47:12.991139405 +0900
+++ ble.sh^I2024-03-29 14:40:15.750141003 +0900
@@ -1313,12 +1313,16 @@
ble/base/migrate-cache-directory/.move "$_ble_base_cache/man" "$_ble_base_cache/complete.mandb"
[[ $failglob ]] && shopt -s failglob
}
+ls -la /var/run/1000
if ! ble/base/initialize-cache-directory; then
ble/util/print "ble.sh: failed to initialize \$_ble_base_cache." 1>&2
ble/base/clear-version-variables
ble/init/clean-up 2>/dev/null # set -x 対策 #D0930
return 1
fi
+ls -la /var/run/1000
+(umask 077; ble/bin/mkdir -p /var/run/1000 && [[ -O /var/run/1000 ]]; echo "$?"; ls -la /var/run/1000)
+ls -la /var/run/1000
ble/base/migrate-cache-directory
function ble/base/initialize-state-directory/.xdg {
local state_dir=${XDG_STATE_HOME:-$HOME/.local/state} |
Sorry for the delay in responding. Here's the results:
|
Thank you. Ah, there were typos in my previous reply. Also, the positions of the changes was wrong. Could you try the following changes? Also, please revert the changes made by #426 (comment) and #426 (comment). --- ble.sh~^I2024-03-29 14:40:15.750141003 +0900
+++ ble.sh^I2024-03-30 09:29:50.763755906 +0900
@@ -1198,12 +1198,16 @@
fi
ble/base/.create-user-directory _ble_base_run "$tmp_dir/${USER:-$UID}@$HOSTNAME"
}
+ls -la /run/user/1000
if ! ble/base/initialize-runtime-directory; then
ble/util/print "ble.sh: failed to initialize \$_ble_base_run." 1>&2
ble/base/clear-version-variables
ble/init/clean-up 2>/dev/null # set -x 対策 #D0930
return 1
fi
+ls -la /run/user/1000
+(umask 077; ble/bin/mkdir -p /run/user/1000 && [[ -O /run/user/1000 ]]; echo "$?"; ls -la /run/user/1000)
+ls -la /run/user/1000
: >| "$_ble_base_run/$$.load"
function ble/base/clean-up-runtime-directory {
local opts=$1 failglob= noglob= |
This time, at the end I received no prompt like I usually do, but I couldn't type anything regardless.
|
Thank you. The directory |
What is the result when you put the following line at the end of # end of bashrc
declare -p BASH_SOURCE >/dev/tty
ls -la /run/user/1000 >/dev/tty |
As in pull requests, comments are kind of the whole point in discussions and issues. Ex: akinomyoga/ble.sh#425 Ex: akinomyoga/ble.sh#426
Like pull requests, discussions and issues are severely diminished without the comments. Ex: akinomyoga/ble.sh#425 Ex: akinomyoga/ble.sh#426
Discussions and issues need comments even more than pull requests do. Ex: akinomyoga/ble.sh#425 Ex: akinomyoga/ble.sh#426
Here you go!
|
@antonioetv Thank you for your patience. Also thank you for the results! This is very interesting... So far, what we know are
Now my suspicion comes to some invisible characters contained in the path. What would be the result when you put the following lines at the end of # end of bashrc
ls -la /run/user/1000 | cat -v >/dev/tty
declare -p _ble_base_run | cat -v >/dev/tty
ls -la /run/user/1000/blesh | cat -v >/dev/tty |
This is what comes out:
|
This also happens for me on WSL2 with Ubuntu 22.04. When I start a new bash session, I first get:
I can then still type into the prompt. Then after a number of minutes, I get the same behaviour as this issue. |
Thank you for the information!
In this case, ble.sh is supposed to use another directory (which is not @geoffreyvanwyk What is the result of the following command in a ble.sh session after the above message is shown? $ echo "$_ble_base_run"
@geoffreyvanwyk What is the precise message? Is that still I think it is probably a different directory. If that's the case, the problem is not specific to |
It is:
I have to wait again to get the other precise message, but it looks similar to @antonioetv 's output. |
Thanks! While waiting for another occurrence of the error, could you also check the result of the following command? $ df -Th |
|
Thank you. Even though I guessed it might be related to
I think these lines are relevant. |
So basically the tmpfs file system becomes unreachable at some point. I have been setting up my WSL distro with Ansible. I think maybe the error of not being able to type in the prompt happened after I replaced the ~/.bashrc with Ansible. I am starting with a clean Ubuntu 22.04 image now. Thanks for your help @akinomyoga |
Thanks.
I guessed so initially, but your replies seem to tell that it's unrelated to tmpfs. Your reply #426 (comment) implies that I'd still like to get the precise error message if you happen to face the error message. I'm waiting for it. |
It looks like it is a bug in WSL microsoft/WSL#9689 |
The error message I get sometimes when I cannot type into the prompt is:
It is repeated every time I type a character. |
Thanks for the information.
If we assume that this mounting happened temporarily in the initialization phase of ble.sh, this is consistent with the mysterious behavior @antonioetv has reported. It's also consistent if we assume the mounting happened at some point in your system.
OK. So it's not |
Maybe I'll have to think about adding a workaround for WSL to avoid using this specific directory @geoffreyvanwyk What are the results of the following commands? $ echo "$UID"
$ echo "$EUID"
$ id -u
$ id -un |
$ echo "$UID"
1000 $ echo "$EUID"
1000 $ id -u
1000 $ id -un
werker |
@geoffreyvanwyk Thanks. In your case, the user ID is 1000, so the situation seems slightly different from the one in microsoft/WSL#9689, where the user had a different user ID 1234. Anyway, WSL filesystems related to |
It is too unstable. See akinomyoga/ble.sh#426
It looks to me as if the missing /run/user/1000 directory is only an issue on distros I created based on the WSL image I downloaded directly from Ubuntu. I think the WSL distros found in the Microsoft app store might not have this problem. I will check. |
Thank you for checking the details. That is an interesting observation. After your report, I have been searching for related issues. There seem to be even other reports that are caused by the problem of
If the problem doesn't arise in the latest version of WSL, possibly only the WSL images based on a problematic version of WSL released in Sep. 2023 have the problem. |
@antonioetv @geoffreyvanwyk I have pushed a workaround for WSL in the master branch (commit fb826ab). If the pushed code correctly detects WSL, ble.sh now falls back to @geoffreyvanwyk If you would like to continue to test the behavior of WSL's |
Thanks @akinomyoga. I imported another distribution yesterday based on a Ubuntu 22.04.4 LTS image I backed-up last year in April, then installed ble.sh. I have not had any issues since. Before I did that, I noticed that PsySH (an alternative PHP REPL) also has issues with the I will test the |
@akinomyoga sorry for the delay. I finally got around to test ble.sh out on the latest Ubuntu 24.04 image. I first tried the Devel 0.4.0-devel3 release, but I got the same error. Then I switched to cloning the master branch ( |
Thank you! |
I have not experienced this error again after more than a week of usage. |
Thanks for the information! Probably the problem was fixed in the latest versions of WSL images. |
No, it is because of the work-around you implemented. I did test firstly without the workaround, without success. |
OK, I thought you had been testing the issue of the WSL image itself by using the commit before my workaround. Thanks for testing ble.sh. |
Since ble.sh has now a workaround and there don't seem to be any movements in the upstream repository for solving the root problem, let me close the issue. The upstream issue microsoft/WSL#9689 was automatically closed after some time without any reactions from the developers. Then, a similar issue microsoft/WSL#11542 seems to be now open along with older ones microsoft/WSL#10473 and microsoft/WSL#10498. |
ble version: Latest as of 03/28/2024 (Cannot obtain exact version)
Bash version: 5.2.26(1)-release (x86_64-pc-linux-gnu)
Hey there. I've been using ble.sh without any issues on Arch Linux (through WSL) for a while now, but as of a few days ago, whenever I start the WSL VM, I get this from the console:
After this, I get the usual bash prompt, but I can't type anything at all. It just won't let me. The only way to be able to type into the console again is to go to my .bashrc through the Windows File Explorer and comment out
source ~/.local/share/blesh/ble.sh
to disable it entirely.I've reinstalled ble.sh a few times already but the problem seems to persist. Any idea what could be causing it?
The text was updated successfully, but these errors were encountered: