Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1511885
Description of problem: The 389-ds-base package in RHEL 7.5 Beta creates the /usr/lib/sysctl.d/70-dirsrv.conf which contains optimized Kernel settings. However, they are not used by the Kernel before you either run # sysctl -p /usr/lib/sysctl.d/70-dirsrv.conf or reboot the system. Version-Release number of selected component (if applicable): 389-ds-base-1.3.7.5-9.el7.x86_64 How reproducible: Always. Steps to Reproduce: 1. Install 389-ds-base/RHDS on RHEL 7.5 Beta 2. Display the current value of e. g. net.ipv4.tcp_fastopen, that is used by the Kernel right after the installation: # sysctl net.ipv4.tcp_fastopen Shows 0 (default), but should be 1027 (according to 70-dirsrv.conf) Actual results: The values from /usr/lib/sysctl.d/70-dirsrv.conf are not used by the Kernel right after the installation. Expected results: The RPM should automatically run # sysctl -p /usr/lib/sysctl.d/70-dirsrv.conf after the installation to make the new Kernel settings available, without rebooting or manually running this command.
Metadata Update from @firstyear: - Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1511885
Metadata Update from @firstyear: - Issue assigned to firstyear
<img alt="0001-Ticket-49449-Load-sysctl-values-on-rpm-upgrade.patch" src="/389-ds-base/issue/raw/files/415847b6fe5df6634f9034da8e63dd9e6eb4eff737b256e71efe595bf40f7ef0-0001-Ticket-49449-Load-sysctl-values-on-rpm-upgrade.patch" />
Metadata Update from @firstyear: - Custom field component adjusted to None - Custom field origin adjusted to None - Custom field reviewstatus adjusted to review - Custom field type adjusted to None - Custom field version adjusted to None
The patch looks good but do you think it is safer to use sysctl --system rather than just reload 389-ds systemd conf file with 'sysctl --load <389-conf-file>' ?
The issue is that sysctl has some quirks - it loads things "in order". So if we direct load a file, we may not see the results of local changes that would over-ride it.
Additionally, if a file of the same name is already loaded, then we also don't load the system one. So:
touch /etc/sysctl.d/70-dirsrv.conf sysctl --system
Has a different result to:
sysctl -p /usr/share/sysctl.d/70-dirsrv.conf
In the former, our /usr version is skipped - in the latter, we load our file, and it will be unloaded next reboot.
So using --system is good as it simulates a reboot and what the values will be when the system restarts, rather than allowing odd transient errors to exist.
That's why I chose this flag :)
@firstyear thanks for your complete explanation !! ACK
Metadata Update from @tbordaz: - Custom field reviewstatus adjusted to ack (was: review)
commit 4f2207a To ssh://git@pagure.io/389-ds-base.git af11fb8..4f2207a master -> master
Metadata Update from @firstyear: - Issue close_status updated to: fixed - Issue status updated to: Closed (was: Open)
ab6d319..9109af6 389-ds-base-1.3.7 -> 389-ds-base-1.3.7
Metadata Update from @vashirov: - Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/2508
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: fixed)
Login to comment on this ticket.