Open tyressk opened 5 months ago
What makes you think this is a bug in Wayfire and not in wallock? (i.e what should Wayfire do that it doesn't?)
Sorry, I don't have much to give on this except that wallock is shut down in Hyprland (kills app and allows it to do its socket removal cleanup). Sway also doesn't kill it.
Actually, my "session leader" theory was wrong too because the app has a --no-daemonize flag that makes it run as RLl+ and it still isn't shut down in wayfire, and since it's the only L process I have running I'm inclined to think it's the memory lock.
I did an interesting experiment though and ran a simple C app that locks the memory:
#include <stdio.h>
#include <stdlib.h>
#include <unistd.h>
#include <sys/mman.h>
int main() {
size_t pagesize = getpagesize();
void* buffer = malloc(pagesize);
if (buffer == NULL) {
perror("Failed to allocate memory");
return 1;
}
// Lock the memory
if (mlock(buffer, pagesize) == -1) {
perror("Failed to lock memory");
free(buffer);
return 1;
}
printf("Memory locked");
// Sleep for 1 hour
sleep(3600);
// Unlock the memory
munlock(buffer, pagesize);
free(buffer);
return 0;
}
When I run this alongside wallock, they both get cleaned up when I do wayland-logout
on wayfire (not on sway though)
Describe the bug Session still shows on
loginctl list-sessions
asstate=Closing
if a session leader app is running before wayland-logout is called. One such app is wallock, whichps aux
lists asSTAT=RLsl
and continues running even as wayfire is exited.To Reproduce Steps to reproduce the behavior:
Expected behavior Session should exit
Wayfire version Current master