[Solved] Some sysctl values are lost after suspend/resume
[Solved] Some sysctl values are lost after suspend/resume
Run 'system -w vm.dirty_bytes=5000000'
Suspend the system...
Resume, and vm.dirty_bytes is 0 again.
Put it in sysctl.conf, run 'sysctl -p', suspend and resume... Same thing.
Word is that this is a feature (no, I've no idea how) and will not be fixed. Given that, what is the least kludgy way to make Salix run 'sysctl -p' on resume?
Suspend the system...
Resume, and vm.dirty_bytes is 0 again.
Put it in sysctl.conf, run 'sysctl -p', suspend and resume... Same thing.
Word is that this is a feature (no, I've no idea how) and will not be fixed. Given that, what is the least kludgy way to make Salix run 'sysctl -p' on resume?
Re: Some sysctl values are lost after suspend/resume
You could create a hook in /etc/pm/sleep.d
https://wiki.archlinux.org/index.php/Pm ... _own_hooks
has some detailed info.
https://wiki.archlinux.org/index.php/Pm ... _own_hooks
has some detailed info.
Re: Some sysctl values are lost after suspend/resume
Thanks, that's what I was looking for!
Edit: to be fair this is still a kludge, since stuff not in sysctl.conf won't be applied. Even so, it helps.
Edit: to be fair this is still a kludge, since stuff not in sysctl.conf won't be applied. Even so, it helps.
Re: Some sysctl values are lost after suspend/resume
Sure, but how often are you changing things like that on the fly?
(I guess I haven't found the power of these options)
(I guess I haven't found the power of these options)
Re: Some sysctl values are lost after suspend/resume
Well, for starters vm.dirty_bytes is rather handy for preventing I/O starvation on desktops, at the expense of disk throughput. It can prevent those scenarios where some program is writing huge batches of stuff to the disk and other programs can't get a word in edgewise. 

Re: Some sysctl values are lost after suspend/resume
Okay, something is going wrong here. sysctl -p is running but the changes are being undone.
00sysctl is properly set +x and looks like this:
What am I doing wrong?
Code: Select all
/usr/lib/pm-utils/sleep.d/01grub resume suspend: success.
Running hook /etc/pm/sleep.d/00sysctl resume suspend:
vm.dirty_bytes = 5000000
...
# sysctl vm.dirty_bytes
vm.dirty_bytes = 0
Code: Select all
#!/bin/bash
case $1 in
thaw)
sysctl -p
;;
resume)
sysctl -p
;;
*)
;;
esac
Re: Some sysctl values are lost after suspend/resume
Hate to do this, but... bump?
Re: Some sysctl values are lost after suspend/resume
Probably something else is running afterwards but I wouldn't know what. You could try this:
Apparently this information is from a log:
Code: Select all
grep -i sysctl /etc/pm/ /usr/lib64/pm-utils/ -r
You could try to get some information from there what is resetting them. Possibly by increasing the verbosity.GJones wrote:Code: Select all
/usr/lib/pm-utils/sleep.d/01grub resume suspend: success. Running hook /etc/pm/sleep.d/00sysctl resume suspend: vm.dirty_bytes = 5000000 ... # sysctl vm.dirty_bytes vm.dirty_bytes = 0
Re: Some sysctl values are lost after suspend/resume
The only invocation of sysctl I found was this:
Which I'm pretty sure is not responsible.
Code: Select all
# grep -ir sysctl /usr/lib64/pm-utils/
/usr/lib64/pm-utils/sleep.d/99video: sysctl -w kernel.acpi_video_flags=$acpi_flag
Re: Some sysctl values are lost after suspend/resume
N/M got it, it's /usr/lib64/pm-utils/power.d/laptop-mode (writing directly to /proc/sys/vm/dirty_ratio and whatnot). Overriding that via an empty /etc/pm/power.d/laptop-mode file works okay.