Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

3 Answers 3

up vote 2 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
2  
actually rc.local is not a bad method either in my opinion. –  johnshen64 Mar 26 '12 at 21:45

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 at 23:23

Your Answer

 
discard

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.