Log Spew From sysctl
Recently at work I browsed some servers logs. In the CentOS 7 containers I noticed a spew of entries like the following:
systemd-sysctl: Failed to write ‘0’ to ‘/proc/sys/kernel/yama/ptrace_scope’: Read-only file system systemd-sysctl: Failed to write ‘16’ to ‘/proc/sys/kernel/sysrq’: Read-only file system systemd-sysctl: Failed to write ‘1’ to ‘/proc/sys/kernel/core_uses_pid’: Read-only file system systemd-sysctl: Failed to write ‘1’ to ‘/proc/sys/fs/protected_hardlinks’: Read-only file system systemd-sysctl: Failed to write ‘1’ to ‘/proc/sys/fs/protected_symlinks’: Read-only file system
Some digging revealed the spew was caused by some hard-coded
/usr/lib/sysctl.d directory is created by the systemd package.
The Red Hat developers decided to hard-code certain kernel system control tunables in this directory rather than follow decades of conventional storage in
/etc. Yes, I know the free desktop specs allow for that location. My guess is the systemd folks at Red Hat wrote the spec.
Hard-coding tunable parameters in
/usr/lib/sysctl.d is a poor decision. When some of these tunables are run in an unprivileged container, sysctl does not have write access to the tunable parameters. This creates the log spew.
Renaming or removing the
/usr/lib/sysctl.d/*.conf files is somewhat futile. When the systemd package is updated the *.conf files return. The files could be tagged as immutable (
chattr +i), but that might cause package support scripts to fail.
Fortunately, all sysctl *.conf files follow rules of precedence. Files with the same name in
/etc/sysctl.d override those found
/run/sysctl.d/, which in turn override files of the same name found in
In our use case I copied the *.conf files from
/etc/sysctl.d and then commented out to disable the unprivileged sysctl parameters on CentOS systems running as containers.
Bare metal systems are not affected.
I wish people would stop reinventing the wheel.