debcrafters-packages team mailing list archive
-
debcrafters-packages team
-
Mailing list archive
-
Message #07483
[Bug 2125011] Re: bash read command hangs on WSL1 with WSL 2.6.0 and later
** Description changed:
- Tested with WSL 2.6.0 and 2.6.1, wsl-setup is not hanging in the cloud-init wait step, but rather at reading input with the command
- `read -e -p "<SOME_PROMPT>" -i somevar`.
+ Tested with WSL 2.6.0 and 2.6.1, but other versions are not discarded.
+ The command `read -e -p "SOME PROMPT: " somevar` appears to hang forever
+ on questing on WSL1. It succeeds in WSL2. Older versions of Ubuntu
+ succeed in both WSL1 and WSL2, such as plucky and noble. That's just the
+ appearance, the prompt is not shown, giving impression that the process
+ is stuck when it's really just waiting for user input but without
+ telling them that's the case.
- The exact same command works in Plucky, where bash version is the same (GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu); read is a shell builtin, not a real executable).
- So, no logic error at the cloud-init step, but some unrelated regression to debug.
+ The exact same command works in Plucky, where bash version is the same
+ (GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu); read is a
+ shell builtin, not a real executable).
+
+ On questing set up appears to fail, though it produces a broken
+ instance, broken in the sense that the shell prompts are not visible.
+ One can type commands and see their outputs, but we don't see MoTD, nor
+ the shell prompt.
+
+ ```
+
+ ```
-- Edited from:
Tested with WSL 2.6.0 and 2.6.1, wsl-setup is hanging in the cloud-init wait step. That shouldn't be the case since the script checks if systemd is running before checking for cloud-init, so this must be a logic error.
** Description changed:
Tested with WSL 2.6.0 and 2.6.1, but other versions are not discarded.
The command `read -e -p "SOME PROMPT: " somevar` appears to hang forever
on questing on WSL1. It succeeds in WSL2. Older versions of Ubuntu
succeed in both WSL1 and WSL2, such as plucky and noble. That's just the
appearance, the prompt is not shown, giving impression that the process
is stuck when it's really just waiting for user input but without
telling them that's the case.
The exact same command works in Plucky, where bash version is the same
(GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu); read is a
shell builtin, not a real executable).
On questing set up appears to fail, though it produces a broken
instance, broken in the sense that the shell prompts are not visible.
One can type commands and see their outputs, but we don't see MoTD, nor
the shell prompt.
```
+ $ wsl.exe --install --from-file '.\questing-wsl-amd64.wsl' --location .\Q1 --name Q1 --version 1
+ Installing: .\questing-wsl-amd64.wsl
+ Distribution successfully installed. It can be launched via 'wsl.exe -d Q1'
+ Launching Q1...
+ Provisioning the new WSL instance Q1
+ This might take a while...
+ kkk
+ New password: kkk
+ Retype new password: kkk
+ passwd: password updated successfully
+ usermod: no changes
+ <3>WSL (10 - SessionLeader) ERROR: SendMessage:131: Failed to write message LxInitOobeResult. Channel: OOBE
+ <3>WSL (10) ERROR: Broken pipe @C:/__w/1/s/src/shared/inc\SocketChannel.h:132 (SendMessage)
+ <3>WSL (10 - SessionLeader) ERROR: CreateProcessCommon:805: Create process failed
+
+ $ wsl.exe -d Q1
+ Provisioning the new WSL instance Q1
+ This might take a while...
+ asasa
+ -bash: line 1: asasa: command not found
+ whoami
+ kkk
+ ps auxf
+ USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
+ root 1 0.0 0.0 11128 1108 ? Ssl 10:28 0:00 /init
+ root 6 0.0 0.0 11144 804 ? Sl 10:28 0:00 plan9 --control-socket 6 --log-level 4 --server-fd 7 --pipe-fd 9 --socket-path /mnt/c/Users/cn/Downloads/Q1/fsserver --log-truncate
+ root 82 0.0 0.0 11156 604 tty1 Ss 10:29 0:00 /init
+ kkk 83 0.1 0.0 13116 2188 tty1 S 10:29 0:00 \_ -bash
+ kkk 117 75.0 0.0 15092 2716 tty1 R 10:29 0:00 \_ ps auxf
+ sudo apt update
+ [sudo: authenticate] Password: sudo: Authentication failed, try again.
+ [sudo: authenticate] Password: sudo: Authentication failed, try again.
+ [sudo: authenticate] Password: sudo-rs: Maximum 3 incorrect authentication attempts
+ kkkk
+ -bash: line 5: kkkk: command not found
+ sudo apt update
+ [sudo: authenticate] Password: sudo: Authentication failed, try again.
+ [sudo: authenticate] Password: sudo: Authentication failed, try again.
+ [sudo: authenticate] Password: sudo-rs: Maximum 3 incorrect authentication attempts
+ su
+ Password: kkk
```
+
+ In the excerpt above one can notice that bash itself it's not showing
+ its prompt but stays responsive, commands typed are executed and their
+ outputs are presented.
-- Edited from:
Tested with WSL 2.6.0 and 2.6.1, wsl-setup is hanging in the cloud-init wait step. That shouldn't be the case since the script checks if systemd is running before checking for cloud-init, so this must be a logic error.
** Summary changed:
- bash read command hangs on WSL1 with WSL 2.6.0 and later
+ bash cannot show prompts on WSL1
--
You received this bug notification because you are a member of
Debcrafters packages, which is subscribed to bash in Ubuntu.
https://bugs.launchpad.net/bugs/2125011
Title:
bash cannot show prompts on WSL1
Status in bash package in Ubuntu:
New
Bug description:
Tested with WSL 2.6.0 and 2.6.1, but other versions are not discarded.
The command `read -e -p "SOME PROMPT: " somevar` appears to hang
forever on questing on WSL1. It succeeds in WSL2. Older versions of
Ubuntu succeed in both WSL1 and WSL2, such as plucky and noble. That's
just the appearance, the prompt is not shown, giving impression that
the process is stuck when it's really just waiting for user input but
without telling them that's the case.
The exact same command works in Plucky, where bash version is the same
(GNU bash, version 5.2.37(1)-release (x86_64-pc-linux-gnu); read is a
shell builtin, not a real executable).
On questing set up appears to fail, though it produces a broken
instance, broken in the sense that the shell prompts are not visible.
One can type commands and see their outputs, but we don't see MoTD,
nor the shell prompt.
```
$ wsl.exe --install --from-file '.\questing-wsl-amd64.wsl' --location .\Q1 --name Q1 --version 1
Installing: .\questing-wsl-amd64.wsl
Distribution successfully installed. It can be launched via 'wsl.exe -d Q1'
Launching Q1...
Provisioning the new WSL instance Q1
This might take a while...
kkk
New password: kkk
Retype new password: kkk
passwd: password updated successfully
usermod: no changes
<3>WSL (10 - SessionLeader) ERROR: SendMessage:131: Failed to write message LxInitOobeResult. Channel: OOBE
<3>WSL (10) ERROR: Broken pipe @C:/__w/1/s/src/shared/inc\SocketChannel.h:132 (SendMessage)
<3>WSL (10 - SessionLeader) ERROR: CreateProcessCommon:805: Create process failed
$ wsl.exe -d Q1
Provisioning the new WSL instance Q1
This might take a while...
asasa
-bash: line 1: asasa: command not found
whoami
kkk
ps auxf
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 11128 1108 ? Ssl 10:28 0:00 /init
root 6 0.0 0.0 11144 804 ? Sl 10:28 0:00 plan9 --control-socket 6 --log-level 4 --server-fd 7 --pipe-fd 9 --socket-path /mnt/c/Users/cn/Downloads/Q1/fsserver --log-truncate
root 82 0.0 0.0 11156 604 tty1 Ss 10:29 0:00 /init
kkk 83 0.1 0.0 13116 2188 tty1 S 10:29 0:00 \_ -bash
kkk 117 75.0 0.0 15092 2716 tty1 R 10:29 0:00 \_ ps auxf
sudo apt update
[sudo: authenticate] Password: sudo: Authentication failed, try again.
[sudo: authenticate] Password: sudo: Authentication failed, try again.
[sudo: authenticate] Password: sudo-rs: Maximum 3 incorrect authentication attempts
kkkk
-bash: line 5: kkkk: command not found
sudo apt update
[sudo: authenticate] Password: sudo: Authentication failed, try again.
[sudo: authenticate] Password: sudo: Authentication failed, try again.
[sudo: authenticate] Password: sudo-rs: Maximum 3 incorrect authentication attempts
su
Password: kkk
```
In the excerpt above one can notice that bash itself it's not showing
its prompt but stays responsive, commands typed are executed and their
outputs are presented.
-- Edited from:
Tested with WSL 2.6.0 and 2.6.1, wsl-setup is hanging in the cloud-init wait step. That shouldn't be the case since the script checks if systemd is running before checking for cloud-init, so this must be a logic error.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/bash/+bug/2125011/+subscriptions
