Closed schaefi closed 1 year ago
@m-kat I did several experiments with this two pass system based on a port for the command and a port for its execution and I could handle also interactive commands like "bash". We are creating an socat dependency but I could live with that.
All up for a conversation and of course I'm open for better ideas :)
Thanks
I was thinking about resolving the interactive commands and think your idea is perfect. even if we are building a dependency on socat it is not the worst we could get, all other options seem to be very complex and not so easy to implement
I was thinking about resolving the interactive commands and think your idea is perfect. even if we are building a dependency on socat it is not the worst we could get, all other options seem to be very complex and not so easy to implement
Ok great that we are on the same page. Let me do some further tests and thanks for the review
@m-kat I found the problem with the broken console when starting firecracker as a child. I solved it by setting stdout and stderr of the child to be piped. This is only done if PILOT_DEBUG is not set and if we are running firecracker as a background process.
I did not find a solution to the quoting issue so far and I the port number creation can be more stable as we discussed. I will add issues for that such that we don't forget. Thanks
The former implementation used the vsock channel to read the command, call it in a child and send the output back through the vsock channel. This works until the command is not interactive. With this refactor I propose a different way to handle the command execution.
start vsock listener on VM_PORT, wait for command(s) in a loop. A received command turns into a socat process using a pseudo terminal (pts) and output that can be retrieved by simply connecting to the EXEC_PORT
Example:
The above procedure needs to be implemeted as part of the firecracker-pilot resume code
Thoughts ?