bustd
bustd copied to clipboard
Make free ram threshold configurable
Is it a good idea to make https://github.com/vrmiguel/bustd/blob/22470c4b351527ff75e0c4e71a55f0c675a21614/src/monitor.rs#L64 configurable ?
I personally have a pc that's very constrained on resource so I'm using bustd with that setting changed to 5, or else the killing of process happens earlier that I want. But my pc is old so I don't know how frequent this use-case is.
One obvious problem of making it configurable , is if the user sets a value like 100% it might theoretically kill all his session? maybe there should a be an acceptable range.
Also maybe a list of should not be touched process should be there somewhere, not necessarily in bustd but at least documented and advised to use with the glob flag
I'm thinking mainly of package managers, for example if pacman is installing an update and the system is low on memory, what if bustd kills it, it will corrupt the system
But like I said it might be not bustd issue (the distro maintainers can set this for example), I'm not sure what other tools like it do, but it something to think about it I guess
Actually bustd did kill pacman once and gnome shell once xD
The way I'm using it now is I'm running it as a user process so it can't kill privileged process, which I think its fine since usually its user programs are the one that consume the memory anyway
I also used setcap "cap_ipc_lock+ep" /usr/bin/bustd
to allow it to call mlockall
I think this current setup work well, I'll give it sometime to see what happens
Alternatively with systemd:
[Service]
ExecStart = /usr/bin/bustd -n
CapabilityBoundingSet=CAP_IPC_LOCK
This will make the executable loose all capabilities, except the mlockall one
But now I think about it more, I think for this to work properly there is a need for a bit a of support from bustd, in particular either it shouldn't consider process that are higher privilege that it as candidates, or when it fails to kill a process due to privilege mismatch it should remove it from the list of candidates
The above systemd file unfortunately doesn't work, because it also needs cap_kill
but that just restores the original behavior of being able to kill any process
systemd-oomd have it easy because its integrated with the system so each unit can choose to be ignored with ManagedOOMPreference
so distros will just configure critical processes.