feat: use lockfiles to determine if daemon is running #1401
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Description
This PR makes the daemon create and lock a file next to the IPC socket (ex. "/run/user/1000/eww-server_f12a67507f690016.lock"). It also makes the program check if the daemon is running by seeing if the file is locked by another process, instead of sending a ping command to the daemon.
This will fix #255, where a timeout in sending an
opencommand over IPC caused the program to create a new daemon, leading to "zombie windows" being left over by the existing daemon.This will also hopefully make the daemon launch a bit quicker when started as
eww open bar.Additional Notes
i haven't tested this on platforms other than linux
is this a feature or a fix?
this uses the
std::fs::File::try_lockmethod which is cleaner but only available in rust 1.89.0 and above; i have an alternative implementation that usesnix::fcntl::Flockinstead, should i submit the alternative instead?Checklist
Please make sure you can check all the boxes that apply to this PR.
docs/content/maindirectory has been adjusted to reflect my changes.cargo fmtto automatically format all code before committing