WIP: add tty mux functionality to chroot2

[europaul]

This commit adds the ability to control the container's entrypoint process from multiple tty consoles. Mainly it's done to support the simultanious access to the container's console from the serial terminal and the VNC console.

The chroot2 script now accepts two additional argument which are the names of the tty consoles (serial and VNC) to be multiplexed. The script accepts inputs from both consoles and forwards them to the container's entrypoint stdin. The output from the container's entrypoint stdout and stderr is also multiplexed to both consoles. Additionally both consoles forward the common signals such as Ctrl+C, Ctrl+Z, Ctrl+, Ctrl+D to the container's entrypoint process.

[christoph-zededa]

I fear with this approach https://linux.die.net/man/1/isatty will return false - have you tried it?

[europaul]

I fear with this approach https://linux.die.net/man/1/isatty will return false - have you tried it?

yes, tty for sure returns not a tty. is this a problem however?

[christoph-zededa]

I fear with this approach https://linux.die.net/man/1/isatty will return false - have you tried it?

yes, tty for sure returns not a tty. is this a problem however?

Lots of tools check on that and do a different output (https://codesearch.debian.net/search?q=isatty&literal=1 )

Let's say it is manageable ;-)

[europaul]

Lots of tools check on that and do a different output (https://codesearch.debian.net/search?q=isatty&literal=1 )

Let's say it is manageable ;-)

I see. I had the issue that top wasn't working in the ubuntu container I used for testing. But it works in the alpine container. :shrug:

[christoph-zededa]

I see. I had the issue that top wasn't working in the ubuntu container I used for testing. But it works in the alpine container. 🤷

I guess it is busybox top vs procps-ng top.

What about editors?

[rucoder]

@europaul I think you shoud use https://linux.die.net/man/3/posix_openpt and friends to have a pseudo terminal device and not a raw FD if you want terminal programs to work properly. I recommend reading chapter 64 "Pseudoterminals" in this book https://github.com/rangaeeeee/books-raspberrypimagazines/blob/master/The%20Linux%20Programming%20Interface-Michael%20Kerrisk.pdf

[rouming]

Recently I made an attempt to upstream working mux implementation, but in QEMU. I got some feedback, the discussion is here: https://lists.gnu.org/archive/html/qemu-devel/2024-09/msg02968.html . The patch works as is, but obviously there are some things to be addressed if we want to make this upstream. @europaul , if you wish to continue this work, please feel free to take it. Also feel free to take the patch downstream if you give up on this one PR.

[rene]

@europaul , I was revisiting this PR today, FYI @rouming has upstreamed the multiple char backends to QEMU: https://github.com/qemu/qemu/blob/master/chardev/char-fe.c, if we port to our QEMU, should be doable directly from QEMU config...

[rouming]

@europaul , I was revisiting this PR today, FYI @rouming has upstreamed the multiple char backends to QEMU: https://github.com/qemu/qemu/blob/master/chardev/char-fe.c, if we port to our QEMU, should be doable directly from QEMU config...

Hey @rene, the last version is https://patchew.org/QEMU/[email protected]/ There was a concern from the maintainer regarding adding the "mux-be-id" field for each chardev, but unfortunately I did not hear anything back about what other alternative approach I could take. I will rebase this series on the latest master this week and resend, still hoping to get some feedback. If this won't move forward, please feel free to backport it to EVE as-is.

[rene]

@europaul , I was revisiting this PR today, FYI @rouming has upstreamed the multiple char backends to QEMU: https://github.com/qemu/qemu/blob/master/chardev/char-fe.c, if we port to our QEMU, should be doable directly from QEMU config...

Hey @rene, the last version is https://patchew.org/QEMU/[email protected]/ There was a concern from the maintainer regarding adding the "mux-be-id" field for each chardev, but unfortunately I did not hear anything back about what other alternative approach I could take. I will rebase this series on the latest master this week and resend, still hoping to get some feedback. If this won't move forward, please feel free to backport it to EVE as-is.

thanks @rouming , nice to hear from you, btw... :grinning:

[rouming]

thanks @rouming , nice to hear from you, btw... 😀

Right, I'm watching all of you through the github :)

[OhmSpectator]

@europaul do we still need this PR?