chroot_vm example and STDIN question

[pfw]

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

[pfw]

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 -"

[slp]

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.

[pfw]

Thanks @slp - good to know that is behaving as expected even if not ideal for our current use case.