fix(gui-client/windows): delete IPC service logs when user clicks "clear logs"#6280
fix(gui-client/windows): delete IPC service logs when user clicks "clear logs"#6280ReactorScram merged 15 commits intomainfrom
Conversation
The headless Client doesn't have a corresponding IPC service, so the `TerminatingGracefully` message for it was unused. This PR shuffles the messages around into better categories to get rid of unused cases like that. This is also a yak shave towards fixing #5453
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
This was a regression in a recent PR
ReactorScram
changed the title
ReactorScram
changed the title
There was a problem hiding this comment.
So this got added here because both the GUI and the IPC service need it, right?
Could this live in the IPC service and it simply also clears the logs for the GUI? The gui can send its path in the request to delete logs, then this can be a private function in the service module.
There was a problem hiding this comment.
Like, call it with two different paths in the IPC service.
There was a problem hiding this comment.
The IPC service shouldn't even be able to read files inside /home and I like that sandbox quite a lot, since we have to run as root:
I could move it into headless-client since I think gui-client still depends on that?
There was a problem hiding this comment.
I see and I guess the other way round too, we can't modify the files of the IPC service, right?
On Linux, should we even be writing log files? Isn't writing to journald strictly better? (Different topic, I know)
I could move it into
headless-clientsince I thinkgui-clientstill depends on that?
Nah I'd rather not expose utilities like that, esp. since the headless client itself doesn't even use that.
There was a problem hiding this comment.
On Linux, should we even be writing log files? Isn't writing to journald strictly better? (Different topic, I know)
There is https://crates.io/crates/tracing-journald at least.
We could experiment with that for the GUI and let the IPC service just write to stdout.
Not sure what Windows offers.
There was a problem hiding this comment.
Yeah it would be more idiomatic for a systemd service to write to stdout.
But then we'd have to do something special to export zips, since it's no longer just files on disk.
I did move it into headless-client since that's where the IPC service lives for now. We could split it up, but then there's more crates. We could not split it up, but then the "headless client" pound for pound is mostly IPC and IPC service code.
Yes, the GUI can't modify the logs of the IPC service by default. On Windows I didn't find any easy solution, that's why I went with this. On Linux I made an exception by making the logs owned by root:firezone-client, so the GUI actually can modify the logs, since it must run as a member of firezone-client
thomaseizinger
left a comment
thomaseizinger
left a comment
There was a problem hiding this comment.
Approving to unblock but I am wondering if we need to move it into the shared crate.
…actor/clear-ipc-logs
|
I'll merge this as-is and we can split up the IPC service from |
I'd like to get to a point (see #4470) where the API of
|
2 participants
Closes #5453
Tested once on the Windows aarch64 VM. Should always leave 4 files behind, a
.logand a.jsonlfor the GUI and for the IPC service. The "log directory" is a bit of a lie since it's consistently 2 directories on both platforms now.