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

FvwmMFL: fix singletion/locking mechanism #1057

Merged
merged 1 commit into from
Aug 22, 2024
Merged

FvwmMFL: fix singletion/locking mechanism #1057

merged 1 commit into from
Aug 22, 2024

Conversation

ThomasAdam
Copy link
Member

There can only ever be one single instance of FvwmMFL running per FVWM instance/$DISPLAY.

Currently, this is done with logging the PID of the running FvwmMFL process and using that to look up a process with the same PID. This is fragile though as the pid in the saved file might not be the samae PID of FvwmMFL -- therefore, FvwmMFL wouldn't start.

Instead, switch to using a lock file which is predicated per $DISPLAY -- achieving the same result, but less error prone.

Fixes #1054

@ThomasAdam ThomasAdam added the relates:module Issue is in module code label Aug 20, 2024
@ThomasAdam ThomasAdam added this to the 1.1.1 milestone Aug 20, 2024
@ThomasAdam ThomasAdam self-assigned this Aug 20, 2024
modules/FvwmMFL/FvwmMFL.c Show resolved Hide resolved
modules/FvwmMFL/FvwmMFL.c Show resolved Hide resolved
modules/FvwmMFL/FvwmMFL.c Show resolved Hide resolved
modules/FvwmMFL/FvwmMFL.c Show resolved Hide resolved
@@ -246,7 +163,7 @@ static void
HandleTerminate(int fd, short what, void *arg)
{
fprintf(stderr, "%s: dying...\n", __func__);
delete_pid_file();
unlink(lockfile);
unlink(socket_name);
rmdir(socket_basepath);
Copy link
Contributor

@farblos farblos Aug 21, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh, and you probably should not just replace delete_pid_file() by unlink(lockfile), but also complement all calls to unlink(socket_name) by a call to unlink(lockfile) (plus closing the lock file handle)? There are at least two calls to unlink(socket_name) in main that do not also care about the lock file.

Or did I miss something here?

There can only ever be one single instance of FvwmMFL running per FVWM
instance/$DISPLAY.

Currently, this is done with logging the PID of the running FvwmMFL
process and using that to look up a process with the same PID.  This is
fragile though as the pid in the saved file might not be the samae PID
of FvwmMFL -- therefore, FvwmMFL wouldn't start.

Instead, switch to using a lock file which is predicated per $DISPLAY --
achieving the same result, but less error prone.

Fixes #1054
@ThomasAdam ThomasAdam merged commit c71b017 into main Aug 22, 2024
5 checks passed
@ThomasAdam ThomasAdam deleted the ta/gh-1054 branch August 22, 2024 15:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
relates:module Issue is in module code
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

FvmwMFL did not get started because of wrong PID in pid file
3 participants