[CentOS] sysctl -p at startup?

Wed Jan 9 16:13:32 UTC 2013
Emmett Culley <emmett at webengineer.com>

On 01/08/2013 12:39 PM, Leon Fauster wrote:
> Am 08.01.2013 um 20:25 schrieb Emmett Culley:
>> On 01/08/2013 02:58 AM, Michael Simpson wrote:
>>> On 2 January 2013 17:54, Emmett Culley <emmett at webengineer.com> wrote:
>>>> I understand that the contents of /etc/sysctl.conf should be read and
>>>> executed at system startup.  However that never happens and I have to run
>>>> sysctl -p after every reboot to get the settings I want.
>>>> This is happening on every CentOS machine and VM I have.   I can see in
>>>> the startup scripts that "sysctl -e -p /etc/sysctl.conf >/dev/null 2>&1"
>>>>    is run at start up by the "apply_sysctl" function, yet the settings are
>>>> never correct unless I run sysctl -p on the command line.
>>>> Anybody know why that would be?
>>>> It depends on whether the changes you are making using sysctl are being
>>> affected by other processes later on in the startup sequence
>>> I have to run sysctl -p manually in order to stop kernel messages being
>>> printed to the console as even though i have them configured off in my
>>> sysctl this is overridden at some other point and i get to find out all
>>> about SoftMAC and its scanning ways
>>> https://bugzilla.redhat.com/show_bug.cgi?id=760497
>>> mike
>> I ended up putting sysctl -p in to /etc/rc.local, which fixed the problem.  I thought I'd read the rc.local is deprecated, so I resisted using it.  Oh well...
> for sysctl configs i suggest the /etc/sysctl.d directory (create it if ...)
> for example:
> $ cat /etc/sysctl.d/vpn.conf
> net.ipv4.ip_forward = 1
> --
> LF
There was no /etc/sysctl.d directory, so I created one and added a file with sysctl -p on the first line, still no change to my requested settings after a reboot.  So I changed the file to look like:

sysctl -p

and made it executable (just in case :-) and of course that didn't work either.

I've noted that there was a bug reported for RHEL5 that stated this would be fixed in 6.  I guess that didn't happen.  And I am not even certain that it isn't working as expected.

In the mean time I will stick to using /etc/rc.local.