5

Is there a good reason that sysctl is broken into so many configuration files across multiple directories?

Is there a reason I can't delete all the sysctl.d configuration files and put everything in /etc/sysctl.conf?

My system is running Xubuntu 20.04 and sysctl.d directories:

  • /etc/sysctl.d/
  • /usr/lib/sysctl.d/

But there must be other config files with sysctl keys, because if I run:

# sudo sysctl --system

it outputs all the keys from my custom /etc/sysctl.conf file and all the keys from the various sysctl.d files.

However, if I run:

# sudo sysctl -a

it outputs tons of keys not explicitly set (by me anyway).

I guess I also really need to know how to locate all the config files that load sysctl keys into the kernel.

man sysctl only list a total of 6 possible locations for sysctl config files:

  • /run/sysctl.d/ which doesn't exist.
  • /etc/sysctl.d/ which contains 8 configuration files generated by the OS and 99-sysctl.conf symlink to /etc/sysctl.conf.
  • /usr/local/lib/sysctl.d/ which doesn't exist.
  • /usr/lib/sysctl.d/ which contains 3 files set by OS.
  • /lib/sysctl.d/ which is the same as /usr/lib/sysctl.d/ although it doesn't show a symlink.
  • /etc/sysctl.conf my heavily modified sysctl file.

I have gone through all of the individual config files and they do not account for even half of the sysctl keys loaded into the kernel. I understand that some applications can set sysctl keys, but there must be other configuration files loading all these keys into the kernel.

Other than options for sysctl command, the man page doesn't have any other data.

  • Which distro and version of Linux are you using? – user68186 Sep 07 '21 at 12:49
  • "across multiple directories" which directories? – muru Sep 07 '21 at 12:50
  • I edited my question with more information. Thanks! – emptysocket Sep 07 '21 at 13:28
  • 1
    DANGER DANGER! Quit messing around with system-level files. Don't delete anything. Don't put a bunch of unnecessary stuff in /etc/sysctl.conf. You're going to end up with a really broken system. – heynnema Sep 07 '21 at 14:08
  • The individual file usually belongs to different packages apt-file find /etc/sysctl. and so does sysctl.conf (procps), if any of those packages get updated, your changes will be lost. –  Sep 07 '21 at 16:52
  • ...how and in which order the parameters are load is described in man sysctl –  Sep 07 '21 at 16:59
  • "Is there a good reason that sysctl is broken into so many configuration files across multiple directories?" yes there is. 1. continuity. When there is an error the directory with the part with the issue is skipped. When in 1 conf that can't happen. Error means crashed system. 2. to avoid dependencies: files can be ordered and executed in order. In 1 conf that is not possible. and there are lots more reasons :) – Rinzwind Sep 08 '21 at 12:53
  • This is by design for good reason. UBUNTU had no hand in this so seems off topic to me. – Rinzwind Sep 08 '21 at 12:58
  • So it's a Debian or Linux issue, not Ubuntu? – emptysocket Sep 08 '21 at 13:36

1 Answers1

3

/run/sysctl.d/ which doesn't exist.

/run is temporary, changes in it are lost at reboot. So drop-in configuration files in /run are used for modifying the current boot, but without persisting those changes past reboot.

/etc/sysctl.d/ which contains 8 configuration files generated by the OS and 99-sysctl.conf symlink to /etc/sysctl.conf.

This is where configuration from packages that are allowed to be modified by the admin will be kept. dpkg will inform you when your edits conflict with package updates.

/usr/local/lib/sysctl.d/ which doesn't exist.

/usr/local is meant for the admin's use, and packages won't do anything there. You are supposed to make the directory should you need it.

/usr/lib/sysctl.d/ which contains 3 files set by OS.

Files in /usr/lib are not meant to be modified by the admin. Package updates will overwrite changes here.

/lib/sysctl.d/ which is the same as /usr/lib/sysctl.d/ although it doesn't show a symlink.

Since the /usr merge, /bin, /lib, etc. are symlinks to the corresponding directories in /usr.

/etc/sysctl.conf my heavily modified sysctl file.

Left around for backwards compatibility, since people (and scripts and other tools) will still expect it.


Modifying configuration transactionally is easiest when you can just add or remove a file with the exact contents you want, instead of using regexes or whatever to modify a line in the middle of a configuration file filled with who-knows-what. That is why directories allowing drop-in configuration files are highly preferable to single configuration files.

muru
  • 207,970