Skip to content
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

How to exit follow without shutting down the daemon #442

Closed
SpacewaIker opened this issue Jun 5, 2023 · 6 comments
Closed

How to exit follow without shutting down the daemon #442

SpacewaIker opened this issue Jun 5, 2023 · 6 comments

Comments

@SpacewaIker
Copy link

A detailed description of the feature you would like to see added.

When executing pueue follow X, I can see the log of currently-running task X. But how can I exit the follow command (i.e. get back to my shell) without shutting down the daemon? The only thing I've found that seems to do anything is <C-c>, but this shuts down the daemon for some reason.

Explain your usecase of the requested feature

Not sure if I'm using pueue for its intended purpose but I wanted to use it to run a testing/development backend server. I usually just open another tab in my terminal where I just cargo run my backend, but I thought that it would be more practical to use pueue. Just create a task that starts the server, then I can follow whenever I need to look at the log, and get back to my shell after getting the info I needed. That way, the server runs in the background and doesn't clutter my windows.

Also, maybe I should make a new issue for this, but is it possible to define a group of tasks that I can start with one command and stop with another (e.g. a backend server and a frontend server)? A paused task becomes failed when shutting down the daemon so that doesn't work, and I don't see a way to stop or shutdown a task that has no "end" (like a server) without it becoming "failed".

Alternatives

No response

Additional context

No response

@Nukesor
Copy link
Owner

Nukesor commented Jun 6, 2023

C-c is indeed the correct way to stop the follow output.

How do you start the daemon?

I've never heard of this behavior before and it shouldn't happen, since these are two distinct processes.
This feels like your terminal/environment misbehaves, but I might be wrong on that.

@SpacewaIker
Copy link
Author

I used pueued -d to start the daemon. After some more testing it seems that C-c works correctly when I'm not in the terminal instance that spawned the daemon (in the background). For instance, if I have two tabs in my terminal (which is the new Windows Terminal app), and start the daemon in one with pueued -d, I can go in the other tab and follow and C-c without any issues. But if I follow in the first tab, then when I press C-c it will seemingly kill the daemon.

I've also noticed that sometimes the pueue.pid file wasn't deleted (I assume that's how it should works), and I got an error message saying that I had to delete it manually. This might have happened when I shut down my computer without shutting down the daemon. I don't know if this is related or not.

@Nukesor
Copy link
Owner

Nukesor commented Jun 6, 2023

May I ask, which version of pueue you're using (or which OS)?
Especially the PID file issue should be fixed since quite a long time, since the PID is now located in the runtime directory, which is automatically cleared on reboot (at least on unix).

Regarding the C-c, this is pretty much the scenario I expected.
Your terminal somehow also sends the SigInt to the pueued process, which shouldn't happen.
pueued just receives the sigint and reacts as expected and desired, by shutting down.

I strongly suggest to either investigate why your terminal behaves that way, or to simply start pueued as a service via systemd user services or alike.

@SpacewaIker
Copy link
Author

I'm using Pueue client version 3.1.2, downloaded through scoop, on windows 11. The PID file path was C:\Users\username\AppData\Local\pueue\pueue.pid. I don't know if this is supposed to be cleared or not when windows reboots.

@Nukesor
Copy link
Owner

Nukesor commented Jun 6, 2023

Ahh I see.
AFAIU, there's no XDG_RUNTIME_DIR in a tmpfs equivalent for Windows.

I'm open to suggestions on how to handle/prevent such scenarios on Windows, since I'm not familiar what the ideomatic approach to this problem is. Anyhow, this is a different problem, for which we can create a new ticket :)

@SpacewaIker
Copy link
Author

I see, thanks for the help!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants