12

I'm experimenting with large changes to Linux system runtime parameters exposed through the sysfs virtual file system.

What is the most efficient way to maintain these parameters so that they persist across reboots on a RHEL/CentOS-style system?

Is it simply a case of dumping commands into /etc/rc.local? Is there an init script that's well-suited for this? I'm also thinking about standardization from a configuration management perspective. Is there a clean sysfs equivalent to sysctl?

4 Answers 4

7

If it were me, I'd probably create an /etc/sysfs.conf, and an /etc/init.d/sysfsutils init script. Then I could keep all of my sysfs related configs and options separate from everything else. With an init script, it could be managed and handled using the standard idioms for managing services and configurations through SysV init scripts (including service sysfsutils [start|stop|reload|restart|status] on RHEL/CentOS (with a little extra work)).

Even if I didn't bother with the /etc/init.d/sysfsutils script, I'd still put the options into /etc/sysfs.conf and then call/process the contents of that file from a separate script (/etc/rc.local, as a last/lazy option).

Note: Debian and Debian-based distributions (Ubuntu, etc.) already do this, and ship an /etc/sysfs.conf config file and init script with their sysfsutils package. Grabbing those two files from a Debian/Ubuntu box (or the Debian source package for sysfsutils) would probably be a good way to start for replicating it yourself.

2
  • It's an option, but I'd be afraid of OS changes/updates that could potentially interfere with those settings.
    – ewwhite
    Mar 27, 2012 at 12:06
  • @ewwhite: If you want to guarantee that no vendor-provided OS update/change is going to interfere with it, you're going to be limited to working under /usr/local or /opt. I would probably be willing to chance it for a small number of machines (with all important bits backed up). For a large number of boxes, I'd duplicate the setup described above, but under /usr/local, with symlinks from /etc/ and /etc/init.d, respectively. And/or I'd probably build an RPM to do the file installation/distribution. Mar 27, 2012 at 15:21
6

You can also try udev rules depending on what you want to set. For example, on my system I set my SSDs to use the deadline scheduler via /etc/udev/rules.d/60-ssd-scheduler.rules containing:

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

You should be able to match any sysfs attributes via the ATTR mechanism.

2
  • Interesting. I've never considered that.
    – ewwhite
    Oct 13, 2014 at 23:23
  • this rules look good, why distros are not shipping this? May 8, 2015 at 8:57
5

Try the sysfsutils package. In particular, /etc/sysfs.conf should help with this.

2
  • 2
    actually rc.local is not a bad method either in my opinion.
    – johnshen64
    Mar 26, 2012 at 21:45
  • Note that /etc/sysfsutils.conf and the script to apply it is not part of the upstream package (as explained in Christopher's answer). It's only present in some distros, not in Arch Linux for example. I configured systemd to look for an rc.local and used that on my Arch desktop. Jun 19, 2017 at 20:27
3

For Fedora/RHEL/CentOS - the default method to configure sysfs and have it persist across reboots is to use tuned. tuned is a general system tuning infrastucture. For sysfs parameters, create a [sysfs] stanza in your configuration file, and provide a line per variable that you want to set and have persist across reboots.

Also as Lennart Poettering pointed out - systemd has a native capability to provide sysfs settings via dropping a snippet in /etc/tmpfiles.d/

1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .