[Terminal] Dead bash processes stack up when navigating away

[MichaIng]

Whenever navigating to and away from the Terminal page, the bash process is not really killed, but remains in the process list with zero memory usage and no ability to kill it (SIGKILL has no effect). This stacks up with every Terminal visit:

Not sure if probably the reader loop locks it up when still reading the socket? I do no yet fully understand at which points the loops are exited when the page is changed: https://github.com/ravenclaw900/DietPi-Dashboard/blob/main/src/backend/src/terminal.rs

[ravenclaw900]

It's not locked up, the main thread waits for both the reader and writer to die before closing the terminal. The leftover bash process is a "Zombie" (You can see this in the htop "state" column). From the docs:

On some systems, calling wait or similar is necessary for the OS to release resources. A process that terminated but has not been waited on is still around as a “zombie”.

However, bash won't let us "wait" on it to stop, so it stays around.

[MichaIng]

Do I get it right that bash is currently stopped by sending an exit command? Or is this visual only and kill() is what SIGKILLs them? https://docs.rs/tokio/1.13.0/tokio/process/struct.Child.html#implementations

Probably there is a cleaner way, like exit from within bash and then "wait", or sending a SIGTERM and "wait".

Here another docs page on this: https://docs.rs/tokio/1.13.0/tokio/process/index.html#unix-processes

And here a SIGTERM method from the Tokio signal module: https://docs.rs/tokio/1.13.0/tokio/signal/unix/struct.SignalKind.html#method.terminate
EDIT: Ah this seems to be for handling received signals and not for sending signals 🤔.

Another find on this: tokio-rs/tokio#2504

[ravenclaw900]

I'm not using Tokio however, just std::process::Command from the standard library. Anyway, bash is stopped via exit, and then SIGKILLed, since it doesn't respond to SIGTERMs.

EDIT: Ah, it looks like exit is enough, and the SIGKILL is just redundant.

[MichaIng]

Ah right. Do I get it right that this implies std:process:Child? Basically the same, it can wait and kill (SIGKILL) but we'd need SIGTERM + wait or a clean exit from within bash itself.

nix seems to be an option: https://stackoverflow.com/a/58156963/16145737

EDIT:

EDIT: Ah, it looks like exit is enough, and the SIGKILL is just redundant.

Worth a test. Probably in combination with wait, and to be very failsafe with a timeout loop for kill when it takes too long?

[ravenclaw900]

I figured it out. I was writing the exit command to bash, but not the newline! It stops cleanly now, and reaps the PID.

[MichaIng]

Perfect 👍.