-
Notifications
You must be signed in to change notification settings - Fork 10
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
Systemd service dont working #10
Comments
Hi!
Seems to be the problem here:
see https://github.com/hakavlad/prelockd/blob/master/prelockd.service.in please test the corrected file ( |
Are you sure you need Your kernel is already using the patch https://www.phoronix.com/news/MGLRU-LPC-2022 |
Regarding the question whether prelockd is still needed: I am also an Arch Linux user, and with the default MGLRU settings, it is still possible to freeze the box. I have not yet tested whether prelockd helps, but now that I found it, I will test it, too. My objection to your testing methodology is that you use "tail /dev/zero" as a simulation of a memory leak, because it provides overly optimistic expectations whether the OOM killer is able to fix the problem and how long it takes. In fact, while supporting certain clusterware, I found an interesting edge case. A component of the cluster has a memory leak. However, the nature of the leak is such that it only happens when the cluster is operational, from the viewpoint of that component. But, under near-OOM conditions, the internal cluster connectivity check times out, and the leak effectively stops. Thus, the OOM killer never comes. Here is a Python script with approximately the same behavior (a leak stops by itself under near-OOM conditions) that you can use for testing:
|
Also, my objection to MGLRU is that it protects file-backed memory that was accessed in the past X milliseconds. When troubleshooting a server, the first thing that needs to be done is to ssh there. Which is a problem, because, if a server is not under attack, sshd code is likely not accessed in the past X milliseconds, and we are back to square one. |
See https://github.com/hakavlad/file-starve This script reduces available memory, but not to zero. It can be useful for modeling memory leaks and studying the state of the system during leakage. |
Did you try to set hight
Have you observed a problem in practice or is it just a theory? (when using MGLRU with high |
btw |
Did you fix prelockd's systemd service? |
For me it works out of the box if I install I confirm that with MGLRU with the default Arch Linux settings, with my script as a malicious workload, prelockd converts a hard freeze into a sluggish system that still can be accessed via ssh. I have not yet tested whether it is possible to tune MGLRU to achieve the same. |
Greetings!
The daemon for systemd doesn't work for me. It won't even start. The program itself works without issue when started via the terminal.
Here is the debugging from journalctl:
But the same command in the daemon works fine.
Here are the specifications of my system from inxi:
The text was updated successfully, but these errors were encountered: