sysctl::apply doesn't apply the sysctl params changes after provisioning

[walterdolce]

Hi there

Yesterday I was using the sysctl cookbook for the first time to manage some ipv6 related kernel params. I noticed though that after a chef-client run, the params were not being taken into account, meaning that the changes were being set correctly but were not being applied by sysctl.

I'm not sure whether the following is expected behaviour, is by design, or neither of both so probably you can clarify it to me (and future comers).

What I was trying to do was to basically disable ipv6 capabilities so to have the web server handle only IPv4.

Following the interested files.

The attributes:

# attributes/sysctl.rb

default['sysctl']['allow_sysctl_conf'] = true
default['sysctl']['params']['net']['ipv6']['conf']['all']['forwarding'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['all']['accept_source_route'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['all']['accept_redirects'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['all']['disable_ipv6'] = 1

default['sysctl']['params']['net']['ipv6']['conf']['default']['forwarding'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['default']['accept_source_route'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['default']['accept_redirects'] = 0
default['sysctl']['params']['net']['ipv6']['conf']['default']['disable_ipv6'] = 1

default['sysctl']['params']['net']['ipv6']['conf']['enp0s3']['disable_ipv6'] = 1
default['sysctl']['params']['net']['ipv6']['conf']['lo']['disable_ipv6'] = 1

The recipe:

# recipes/default.rb

include_recipe 'sysctl::apply'
# other "include_recipe" lines

I always needed to run sysctl -p /path/to/chef-sysctl-params-file to have the changes applied. Is this behaviour expected?

I was applying this against the CentOS 7 box provided by OpsCode.

Thanks!

[walterdolce]

While double checking the README again I realized:

The configuration will be written out when sysctl::apply gets run, which allows the parameters set to be persisted during a reboot.

It doesn't specify anything except the reboot. So I guess that it is intended behaviour not to apply the changes straight away but at the next reboot.

Will leave this open just to have the author(s) confirm and eventually close. cc @svanzoest

Thanks!

[svanzoest]

@walterdolce do you have log output for this? It should apply the attributes, so I am wondering if it ran into some issue our the procps service function on centos 7 has changed. You should also see the config file in /etc/sysctl.d.

[walterdolce]

Yep attributes get set correctly in the /etc/sysctl.d/99-chef-attributes.conf file. It's just that after applying them they don't have effect. So you'd need to manually use the sysctl -p command.

After looking at the cookbook though I changed strategy and I used the sysctl::default recipe directly and used the sysctl_param LWRP giving it a hash of sysctl parameters => values. This way they get applied straight away.

[joerocklin]

I ran into the same problem when adding support for SLES 12, which also uses systemd. Changing the template resource to notify service[procps] with :restart instead of :start resolved the problem. I have not yet run the full test suite to see if this change has any negative effects elsewhere.

[lmickh]

I can confirm that there is a similar behavior on Debian 8 with systemd as well. Restarting procps instead of using :start seems to be the solution as well.

[svanzoest]

Thanks for all the feedback on this. I have been tied up on other things, but I hope to work on release soon and plan to include some of the ideas discussed in here.

[fletchowns]

Was just about to submit a pr for the same changes @joerocklin made. Any word on when this will be pulled in?

[jslusher]

I would also like to know when the :restart on the template will be put in place. Thanks!

[svanzoest]

It looks like this works everywhere, so we have moved to using restart which will be in the next release

[fletchowns]

Awesome, thanks @svanzoest !

[svanzoest]

0.7.0 has been released with restart.

[lock[bot]]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.