Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
up vote 3 down vote accepted

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.

share|improve this answer
It's an option, but I'd be afraid of OS changes/updates that could potentially interfere with those settings. – ewwhite Mar 27 '12 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. – Christopher Cashell Mar 27 '12 at 15:21

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

share|improve this answer
actually rc.local is not a bad method either in my opinion. – johnshen64 Mar 26 '12 at 21:45

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/

share|improve this answer

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.

share|improve this answer
Interesting. I've never considered that. – ewwhite Oct 13 '14 at 23:23
this rules look good, why distros are not shipping this? – soubunmei May 8 '15 at 8:57

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.