Sat Mar 12 13:05:37 CET 2016
How to break sysctl
A long time ago sysctl used one confg file: /etc/sysctl.conf
There was a simple way to (re)load the values from that file: sysctl -p
There are aliases -f --file that do the same.
Then things were Improved and Enhanced. Now sysctl -p will either fail (bug in procps-3.3.9) or not apply the config (3.3.10+). Which is possibly at times a bit fatal on production machines that rely on nonstandard settings to handle the workload.
How did things break? Of course new config paths must be added. Like any Modern Application sysctl will read snippets from a directory, and not just one directory but six:
So let's think ...
/run ? Why would you put config there. Srsly wat. Use sysctl -w if you want to temporarily set a value.
/etc/sysctl.d ? Looks reasonable.
/usr/local/lib ? WAT. That's not a path where config lives. /usr/lib ? Why do you put things that are not libs in libdir. And since you need to be administrative access person to modify that path, it is like /etc/sysctl.d only strictly worse.
/lib ? oh, because ... uhm ... I can't figure this one out
and finally, the classic /etc/sysctl.conf.
So four of the six new paths are poop, and we could completely remove this misfeature by adding an 'include /etc/sysctl.d/*.conf' to /etc/sysctl.conf. Then we wouldn't need sysctl --system, sysctl -p would still work, and there'd be less code written to implement this misfortune and less code written to mitigate the failures caused by it.
Having to fight such changes and the breakage they cause is frustrating, by changing less we could achieve more.
What amuses me most about this is that this change actually broke the new feature (--system) in the first iteration, after breaking the old behaviour. Amazing amount of churn that doesn't fix a problem we've had. No, I'm not grumpy!
There was a simple way to (re)load the values from that file: sysctl -p
There are aliases -f --file that do the same.
Then things were Improved and Enhanced. Now sysctl -p will either fail (bug in procps-3.3.9) or not apply the config (3.3.10+). Which is possibly at times a bit fatal on production machines that rely on nonstandard settings to handle the workload.
How did things break? Of course new config paths must be added. Like any Modern Application sysctl will read snippets from a directory, and not just one directory but six:
/run/sysctl.d/*.conf
/etc/sysctl.d/*.conf
/usr/local/lib/sysctl.d/*.conf
/usr/lib/sysctl.d/*.conf
/lib/sysctl.d/*.conf
/etc/sysctl.conf
So let's think ...
/run ? Why would you put config there. Srsly wat. Use sysctl -w if you want to temporarily set a value.
/etc/sysctl.d ? Looks reasonable.
/usr/local/lib ? WAT. That's not a path where config lives. /usr/lib ? Why do you put things that are not libs in libdir. And since you need to be administrative access person to modify that path, it is like /etc/sysctl.d only strictly worse.
/lib ? oh, because ... uhm ... I can't figure this one out
and finally, the classic /etc/sysctl.conf.
So four of the six new paths are poop, and we could completely remove this misfeature by adding an 'include /etc/sysctl.d/*.conf' to /etc/sysctl.conf. Then we wouldn't need sysctl --system, sysctl -p would still work, and there'd be less code written to implement this misfortune and less code written to mitigate the failures caused by it.
Having to fight such changes and the breakage they cause is frustrating, by changing less we could achieve more.
What amuses me most about this is that this change actually broke the new feature (--system) in the first iteration, after breaking the old behaviour. Amazing amount of churn that doesn't fix a problem we've had. No, I'm not grumpy!