Bug 892693 - sub-configs in '/etc/sysctl.d' not being loaded as expected
sub-configs in '/etc/sysctl.d' not being loaded as expected
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libvirt (Show other bugs)
x86_64 Linux
unspecified Severity medium
: rc
: 7.0
Assigned To: Eric Blake
Virtualization Bugs
Depends On: 887017
  Show dependency treegraph
Reported: 2013-01-07 10:52 EST by Eric Blake
Modified: 2014-06-17 20:43 EDT (History)
29 users (show)

See Also:
Fixed In Version: libvirt-1.0.2-1.el7
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 887017
Last Closed: 2014-06-13 08:31:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Eric Blake 2013-01-07 10:52:26 EST
Cloning to RHEL.

+++ This bug was initially created as a clone of Bug #887017 +++

The sub-config files located in the folder '/etc/sysctl.d' are not being loaded on bootup.  See below for example.

<after bootup>

[root@desktop ~]# cat /etc/sysctl.d/libvirtd |grep -v ^#
fs.aio-max-nr = 1048576

[root@desktop ~]# cat /etc/sysctl.d/postgresql 

[root@desktop ~]# sysctl -a |grep fs.aio-max-nr
fs.aio-max-nr = 65536

[root@desktop ~]# sysctl -a |grep kernel.shmmax
kernel.shmmax = 33554432

As you can see, the values are not proper after the system boots.  If i manually set the values to the desired setting via the sysctl utility from the CLI, then all is well.

Version is Fedora 18 Beta with current patch level as of today (12/13/2012). see below for actually version number of initscripts....

[root@desktop ~]# rpm -qf /etc/sysctl.conf 

--- Additional comment from Bill Nottingham on 2012-12-13 13:49:24 MST ---

See 'man sysctl.d' - files should end with '.conf'.

--- Additional comment from Nick Nachefski on 2012-12-13 18:04:41 MST ---

Ah, yes... I guess i should file this under the *libvirt-daemon* package then.  The libvirtd file under the /etc/sysctl.d directory (in the libvirt-daemon pacakge) does not have the .conf extension and it's settings are not being applied.

# rpm -qf /etc/sysctl.d/libvirtd

# cat /etc/sysctl.d/libvirtd |grep -v ^#
fs.aio-max-nr = 1048576


--- Additional comment from Eric Blake on 2012-12-15 22:21:58 MST ---

Reading that man page, it sounds like libvirt should be installing into /usr/lib/sysctl.d/libvirt.conf, not /etc/sysctl.d/ - so it is more than just a wrong suffix, but a wrong location.

--- Additional comment from Bill Nottingham on 2012-12-17 12:26:29 MST ---

/etc will work, but /usr/lib/sysctl.d is preferred for system-distributed configurations.

--- Additional comment from Nick Nachefski on 2012-12-18 11:55:37 MST ---

I guess that just leaves the matter of adding the proper '.conf' suffix to the file then.

--- Additional comment from Eric Blake on 2013-01-04 14:05:36 MST ---

In the spec file, how does one guarantee that the file will be installed into /usr/lib/sysctl.d, even when %{_libdir} is /usr/lib64?

--- Additional comment from Kay Sievers on 2013-01-04 14:14:48 MST ---

/usr/lib/<pkgname>/ has nothing to do with %{_libdir} or multi-lib.
It is always:
and treated as the "application private directory" which is the same
for all architectures and systems.

%{_libdir} is for shared libraries and almost nothing else.

--- Additional comment from Eric Blake on 2013-01-04 15:37:27 MST ---

Upstream patch proposed:
Comment 2 Eric Blake 2013-01-07 16:58:57 EST
In POST for RHEL 7 by virtue of the next rebase picking up this upstream commit:

commit a1fd56cb3057c45cffbf5d41eaf70a26d2116b20
Author: Eric Blake <eblake@redhat.com>
Date:   Fri Jan 4 14:21:59 2013 -0700

    build: install libvirt sysctl file correctly
    https://bugzilla.redhat.com/show_bug.cgi?id=887017 reports that
    even though libvirt attempts to set fs.aio-max-nr via sysctl,
    the file was installed with the wrong name and gets ignored by
    sysctl.  Furthermore, 'man systcl.d' recommends that packages
    install into hard-coded /usr/lib/sysctl.d (even when libdir is
    /usr/lib64), so that sysadmins can use /etc/sysctl.d for overrides.
    * daemon/Makefile.am (install-sysctl, uninstall-sysctl): Use
    correct location.
    * libvirt.spec.in (network_files): Reflect this.
Comment 3 Huang Wenlong 2013-01-15 21:30:42 EST
I can reproduce this bug :
rpm -q libvirt-1.0.1-1.el7.x86_64

# rpm -qf /etc/sysctl.d/libvirtd

#  ll /usr/lib/sysctl.d/
total 4
-rw-r--r--. 1 root root 738 Nov 17 23:43 00-system.conf

libvirtd sysctl config file should be in /usr/lib/sysctl.d
Comment 4 Huang Wenlong 2013-02-04 03:29:13 EST
Verify this bug with:

# rpm -qf /usr/lib/sysctl.d/libvirtd.conf

file's path is correct
Comment 5 Bryan Burke 2014-03-02 12:53:20 EST
This, or something like it is also happening in Fedora 19; I'm running a virtual-host, but the /usr/lib/sysctl.d/00-system.conf file is not being loaded in particular (which disables netfiltering on bridged interfaces, and my guests can't get out), but more generally, none of them are getting loaded.

[root@kontinuum]/usr/lib/sysctl.d# rpm -qa fedora-release

[root@kontinuum]/usr/lib/sysctl.d# uname -rvm
3.12.11-201.fc19.x86_64 #1 SMP Fri Feb 14 19:08:33 UTC 2014 x86_64

[root@kontinuum]/usr/lib/sysctl.d# rpm -qf 00-system.conf 

I wonder if this has to do with my disk setup, and / isn't available at the time systemd-sysctl.service runs. (The disk stack is SATA => MD => LVM => LUKS.)

If I should file a new bug, or there's any additional information you need, let me know.
Comment 6 Bryan Burke 2014-03-02 13:06:22 EST
I apologize; after continuing to read through the bugs, I looked again, and I think it is only the 00-system.conf not getting loaded, probably because of the NetworkManager, as suggested in some other bugs. Ignore my previous comment on the bug.
Comment 7 Ludek Smid 2014-06-13 08:31:02 EDT
This request was resolved in Red Hat Enterprise Linux 7.0.

Contact your manager or support representative in case you have further questions about the request.

Note You need to log in before you can comment on or make changes to this bug.