Hi @sherrysim! I have sadly not been able to work on this issue due to
other tasks taking priority.
This issue is a bit complex to troubleshoot as we are dealing with QEMU
along with a few scripts I don't directly have access to. However, I
attempted to reproduce this using a 26.04 LTS LXC guest container
instead with the following minimal reproducer inside the host:
repro.exp:
```
#!/usr/bin/expect -f
set timeout 480
set password "<PASSWORD>"
spawn ssh \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
ubuntu@<ADDRESS>
expect {
"*assword*" {
send "$password\r"
}
timeout {
puts "ERROR: SSH password prompt timeout"
exit 1
}
}
expect {
-re {[$#] $} {
puts "Connected to guest"
}
timeout {
puts "ERROR: shell prompt timeout"
exit 1
}
}
send "sudo ./installer.sh 2>&1 | tee installer_logs.txt\r"
# Wait for the command to finish.
set timeout 480
expect {
-re {[$#] $} {
puts "SUCCESS: installer completed"
exit 0
}
timeout {
puts "TIMEOUT: installer did not return to the shell prompt"
interact
}
}
```
installer.sh:
```
#!/bin/bash
set -x
apt-get update && apt-get upgrade -y
apt-get install ethtool libbpf1 lm-sensors -y
```
After some testing, it seems that the apt-get install is responsible for
the T+ hang. We can see that it's still running after a few minutes:
$ pgrep -a -f 'apt-get|dpkg|sudo'
7851 sudo ./installer.sh
7854 sudo ./installer.sh
7944 apt-get install ethtool libbpf1 lm-sensors -y
With the process tree:
PID PPID PGID SID TPGID STAT WCHAN TTY ELAPSED
COMMAND
4663 1 4663 4663 -1 Ss - ? 28:00
sshd: /usr/sbin/sshd -D
└─7750 4663 7750 7750 -1 Ss - ? 05:59
sshd-session: ubuntu [priv]
└─7828 7750 7750 7750 -1 S - ? 05:59
sshd-session: ubuntu@pts/2
└─7829 7828 7829 7829 7851 Ss do_wait pts/2 05:59
-bash
├─7851 7829 7851 7829 7851 S+ - pts/2 05:58
sudo ./installer.sh
│ └─7854 7851 7854 7854 7855 Ss - pts/3 05:58
sudo ./installer.sh
│ └─7855 7854 7855 7854 7855 S+ - pts/3 05:58
/bin/bash /home/ubuntu/installer.sh
│ └─7944 7855 7855 7854 7855 T+ - pts/3 05:57
apt-get install ethtool libbpf1 lm-sensors -y
└─7852 7829 7851 7829 7851 S+ anon_pipe_read pts/2 05:58
tee installer_logs.txt
More importantly, if we leave out the pipe to `tee` in:
`send "sudo ./installer.sh 2>&1 | tee installer_logs.txt\r"`,
the process exits successfully. The installation is always successful in
both cases, it's just that the process gets stopped when the output is
piped.
I was even able to reproduce this without any ssh involved just using:
```
sudo ./installer.sh | tee installer_logs.txt
```
Interestingly, if we were to pipe the output of a trivial script like:
hello.sh:
```
#!/bin/bash
printf "Hello!\n"
```
$ sudo ./hello.sh | tee output
Hello!
Then the process exits successfully. We can thus deduce that this seems
related to the interaction between sudo-rs and the apt-get install.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/2150073
Title:
sudo‑rs causes apt-get (install or upgrade)to be stopped (T+) in a
non‑interactive SSH session
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rust-sudo-rs/+bug/2150073/+subscriptions
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
