3

I am (probably obviously) a relatively new Linux user, so I'm already bracing for the barrage of "why aren't you doing it this way instead..." comments. I'd love to hear them...but I would also really like to fundamentally understand why this isn't working as is.

The details:

  • I'm running CentOS 7+
  • I'm attempting to modify the read-ahead values on my blockdev configs (for a database server)
  • I'm able to implement the changes from cmd line, but I cannot persist them after reboot.
  • Yes, I have rebooted. A lot.
  • In an attempt to persist the changes I've modified the rc.local file.

  • The rc.local file is being implemented like this: 

    #!/bin/bash
touch /var/lock/subsys/local
/sbin/blockdev --setra 128 /dev/sda
/sbin/blockdev --setra 128 /dev/dm-1
/sbin/blockdev --setra 128 /dev/dm-0
2
  • What are the permissions on the rc.local file?
    – David King
    Dec 4, 2015 at 20:54
  • So, it turns out, that was my issue. I eventually realized that the permissions needed to be adjusted, like so: chmod +x /etc/rc.d/rc.local However, I'm not posting that as an answer...I don't think this approach is really a best practice. @JdeBP's answer below definitely looks like a more sane solution.
    – DCaugs
    Dec 8, 2015 at 13:38

2 Answers 2

Reset to default
6

Forget about rc.local.

You're using CentOS 7. You have systemd. /etc/rc.local is a double backwards compatibility mechanism in systemd, because it is a backwards compatibility mechanism for a mechanism that was itself a compatibility mechanism in System 5 rc. And as shown by the mess in the AskUbuntu question hyperlinked below, using /etc/rc.local can go horribly wrong. So make a proper systemd service unit.

First, create a template service unit. For the sake of example, let's call it /etc/systemd/system/[email protected]:

[Unit]
Documentation=https://unix.stackexchange.com/questions/247436/
Description=Set custom read-ahead on storage device %I
BindsTo=dev-%i.device

[Service]
Type=oneshot
ExecStart=/sbin/blockdev --setra 128 /dev/%I

Arrange for that service unit to be started by the plug-and-play device manager (udev) when the appropriate devices arrive. Your rule, which you'll have to tailor to your specific needs, will look something like:

SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ENV{SYSTEMD_WANTS}="custom-readahead@%k"

The SYSTEMD_WANTS setting causes udev to start the named service — an instantiation of the template against the device %k. This service then runs blockdev.

There is apparently another way of doing this, which relies on udev's ability to set these settings directly. For this, you don't need the systemd template unit or instantiated services. Instead, simply instruct udev directly in its rule:

SUBSYSTEM=="block", ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{bdi/read_ahead_kb}="128"

Notice the difference between == and =.

There is no rc.local involved anywhere, either way.

Further reading

2

In CentOS 7, rc.local is not executable by default.

Run: chmod +x /etc/rc.d/rc.local

To enable it.

You must log in to answer this question.

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