containers
chroot_vm example and STDIN question
I'm trying to understand the handling of STDIN and am a little lost. From the comments in libkrun.h where it says
The VMM will attempt to take over stdin/stdout to manage them on behalf of the process running inside the isolated environment, simulating that the latter has direct control of the terminal.
I'm assuming that something is being done with the STDIN FD of the chroot_vm and therefore the target process STDIN and it looks from running a process with chroot_vm as a subprocess via python that STDIN is getting closed and reopened somehow.
In these lsof listings I can see the parent (75590) has opened PIPEs to the subprocess and STDOUT/STDERR remain open and connected to the chroot_vm child (75622) but the child has FD 0 as a PIPE with no connection back to the parent.
Is this expected? If so what is the recommended way to drive a subprocess where you need to feed input to it's STDIN?
➜ lsof -p75590
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
python3.1 75590 pfw cwd DIR 1,17 192 6234961 .../libkrun/examples/prog
python3.1 75590 pfw txt REG 1,17 33815 4268189 .../.pyenv/versions/3.11.2/bin/python3.11
python3.1 75590 pfw txt REG 1,17 53528 4276793 .../.pyenv/versions/3.11.2/lib/python3.11/lib-dynload/fcntl.cpython-311-darwin.so
python3.1 75590 pfw txt REG 1,17 54867 4276767 .../.pyenv/versions/3.11.2/lib/python3.11/lib-dynload/_posixsubprocess.cpython-311-darwin.so
python3.1 75590 pfw txt REG 1,17 110624 2572457 /opt/homebrew/Cellar/gettext/0.21.1/lib/libintl.8.dylib
python3.1 75590 pfw txt REG 1,17 77033 4276771 .../.pyenv/versions/3.11.2/lib/python3.11/lib-dynload/select.cpython-311-darwin.so
python3.1 75590 pfw txt REG 1,17 101511 4276748 .../.pyenv/versions/3.11.2/lib/python3.11/lib-dynload/math.cpython-311-darwin.so
python3.1 75590 pfw txt REG 1,17 5407488 4268190 .../.pyenv/versions/3.11.2/lib/libpython3.11.dylib
python3.1 75590 pfw 0u CHR 16,6 0t83467 1671 /dev/ttys006
python3.1 75590 pfw 1u CHR 16,6 0t83467 1671 /dev/ttys006
python3.1 75590 pfw 2u CHR 16,6 0t83467 1671 /dev/ttys006
python3.1 75590 pfw 5 PIPE 0xaa73e3d0de8532fb 16384 ->0xa6b137dd3fcc053a
python3.1 75590 pfw 7 PIPE 0xf89f4fafff9312f5 16384 ->0x6802587995e8e280
➜ lsof -p75622
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
chroot_vm 75622 pfw cwd DIR 1,17 192 6234961 .../libkrun/examples/prog
chroot_vm 75622 pfw txt REG 1,17 55248 6119277 .../libkrun/examples/chroot_vm
chroot_vm 75622 pfw txt REG 1,17 74064 5872731 /opt/homebrew/Cellar/dtc/1.7.0/lib/libfdt-1.7.0.dylib
chroot_vm 75622 pfw txt REG 1,17 3714304 5878207 /opt/homebrew/Cellar/libkrun/1.5.1/lib/libkrun.1.5.1.dylib
chroot_vm 75622 pfw txt REG 1,17 17702848 5872578 /opt/homebrew/Cellar/libkrunfw/3.10.0/lib/libkrunfw.3.dylib
chroot_vm 75622 pfw 0 PIPE 0x5a9168da4848861a 16384
chroot_vm 75622 pfw 1 PIPE 0xa6b137dd3fcc053a 16384 ->0xaa73e3d0de8532fb
chroot_vm 75622 pfw 2 PIPE 0x6802587995e8e280 16384 ->0xf89f4fafff9312f5
chroot_vm 75622 pfw 3u KQUEUE count=1, state=0x8
chroot_vm 75622 pfw 4 PIPE 0x27c70e5691c6b5da 16384 ->0x561a22f187d72b2
A single line example of what I'm looking to achieve - STDIN input to a process which then writes back out STDOUT (and/or STDERR)
echo "this and that" | docker run -i busybox sh -c "sleep 5; cat -"
This is actually a known limitation of libkrun. STDIN/STDOUT are tied to the emulated virtio-console, and their interactions are designed with interactive TTY sessions in mind, to the point of tying the lifetime of the VM to STDIN.
We need to revamp this mechanism to properly use non-TTY uses, such as the one you're describing. I'll create an Issue to track this progress.
Thanks @slp - good to know that is behaving as expected even if not ideal for our current use case.