-
-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Terminal exits service #19
Comments
Lol when wrapped into
On every terminal access/reload there is this |
@MichaIng, if the command is wrapped in |
That matches my thoughts, I had that step in mind already 👍. systemd does not deny terminal device access generally, but some step around spawning the PTS somehow expects/requires a terminal attached to STDIN and/or STDOUT already. Probably the order needs to be tweaked. I.e. currently the command is spawned without a PTS, respectively without attaching the process/command to that PTS at first, if I understand it right: https://github.com/ravenclaw900/DietPi-Dashboard/blob/abb0c71/src/backend/src/terminal.rs#L21-L26 I found the docs for the used crate: https://docs.rs/pty-process/0.1.0/pty_process/ If it is somehow difficult to achieve things with it, there seems to be an alternative with uses Tokio explicitly: https://docs.rs/tokio-pty-process/0.4.0/tokio_pty_process/ |
I tried to use |
Ah okay. Probably it works when creating the PTY with a low default size, like: .spawn_pty(&pty_process::Size::new(80,20)) Btw: let cmd_read = Arc::clone(&cmd); does not clone the process or PTY itself but only the reference to the single process and PTS, so that input and output loops can run asynchronously (from each other), right? |
Nope, still failing, with the same error. Yes, that just clones a reference that can be used in both threads. |
Another test would be to explicitly redirect STDIN/STDOUT/STDERR as I'm not sure of other impacts of # STDIN only
./dietpi-dashboard < /dev/null
# All streams
./dietpi-dashboard < /dev/null 2>&1 | tee |
Just a note: it works with nohup if ran manually, but not in the service. Both of those commands also work. |
Right. Not sure how to change that, but regardless of how I wrap commands on a console, they remain "attached" to the shells TTY, when checking via |
Btw, official systemd documentation: https://www.freedesktop.org/software/systemd/man/systemd.service.html |
Hmm, setting |
Does it? Strange, it didn't work for me, but probably I messed with something else when testing around. Will retest. I wonder the implications as in theory this means that input on the local console goes to the dashboard. It doesn't react to it, though, what about CTRL+C? We could however set a TTYPath that is definitely unused, like |
It is strange, if I only add Ah adding additionally So in combination, this works fine here:
For you |
Indeed, I only needed Also, since this isn't directly a problem with the dashboard, I'm now going to make a 0.3.1 release with all of the bugs you caught fixed. |
Yes makes sense, also since the "Stable" release selection is currently broken due to the architecture suffix change, AFAIK 😄. |
+ DietPi-Software | Fix Terminal on DietPi-Dashboard: ravenclaw900/DietPi-Dashboard#19
Okay, we may want to find a cleaner solution, but for now it's fine 👍. Marking this as solved/closed. |
As we found already on the PR at the DietPi repo. There is an exit signal btw:
So a SIGHUP is sent to the main process.
Part of a problem is that in systemd units,
SHELL
==/bin/sh
despiteUser=root
being defined. Not sure how to force it to use users real shell. We should use/bin/bash
here hardcoded, since this also it the only shell where the banner and the command shortcuts are known to work. But forcing/setting the variable does not fix the crash, so it is a dedicated issue.I'm not sure where the SIGHUP signal is coming from, but probably we can force systemd to keep the service active when it is received.
While SIGHUP is often used to reload a service, here it stops it, i.e.
kill -HUP <PID>
stops the process started form console. So this signal seems to be sent only when it is started via web UI. Not sure if a systemd unit has somehow issues with the PTY 🤔.I guess
(*cmd.write().await).kill().unwrap();
usually kills the shell process only, however, I wonder it this can in some circumstances kill the parent process? The writer does already.write_all("exit".as_bytes())
, which should usually be sufficient. Probably we need to add some debug code to check what's going on. I'll now try to run it withstrace
.The text was updated successfully, but these errors were encountered: