Automatically load /usr/lib/sysctl.d/70-dirsrv.conf after installing 389-ds-base

[389-ds-bot]

Cloned from Pagure issue: https://pagure.io/389-ds-base/issue/49449

• Created at 2017-11-13 01:38:35 by firstyear (@Firstyear)
• Closed at 2017-12-01 11:44:56 as fixed
• Assigned to firstyear (@Firstyear)
• Associated bugzillas
  • https://bugzilla.redhat.com/show_bug.cgi?id=1511885

---

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.

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-11-13 01:38:37

Metadata Update from @Firstyear:

• Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1511885

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-11-13 01:38:49

Metadata Update from @Firstyear:

• Issue assigned to Firstyear

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-12-01 09:56:24

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-12-01 09:56:33

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

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2017-12-01 10:27:52

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>' ?

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-12-01 10:39:59

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 :)

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2017-12-01 10:55:28

@Firstyear thanks for your complete explanation !! ACK

[389-ds-bot]

Comment from tbordaz (@tbordaz) at 2017-12-01 10:55:30

Metadata Update from @tbordaz:

• Custom field reviewstatus adjusted to ack (was: review)

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-12-01 11:45:08

commit 4f2207a
To ssh://git@pagure.io/389-ds-base.git
af11fb8..4f2207a master -> master

[389-ds-bot]

Comment from firstyear (@Firstyear) at 2017-12-01 11:45:13

Metadata Update from @Firstyear:

• Issue close_status updated to: fixed
• Issue status updated to: Closed (was: Open)

[389-ds-bot]

Comment from mreynolds (@mreynolds389) at 2017-12-08 20:09:34

ab6d319..9109af6 389-ds-base-1.3.7 -> 389-ds-base-1.3.7

[389-ds-bot]

Comment from vashirov (@vashirov) at 2020-02-12 17:35:34

Metadata Update from @vashirov:

• Issue set to the milestone: None (was: 0.0 NEEDS_TRIAGE)