Do you have documentation as to what and how this is doing for systemd?
I think would be a change to lib389 to do the "correct thing". There is
also a risk that we'll break existing deployments too because we don't
have the ability to "on upgrade" anymore ....

Is there links to a change that systemd have provided here too?

I think we need more info ....

--
Sincerely,

William

All I have so far is the warning in the system log.

But with a quick look into /usr/lib/systemd/system/dirsrv@.service I can see a .include /etc/sysconfig/dirsrv.systemd. Maybe you can use an environment file for this, but i am not sure about this.

@twoerner My concern is upgrades. How are we going to migrate existing services and deployments to use this? I think this is a breaking change, and it won't be easy to resolve :(

We may need a systemd-fixup task in the CLI that fixes it somehow when an admin notices etc. It's just a mess to see a change like this being pushed on us :(

@twoerner My concern is upgrades. How are we going to migrate existing services and deployments to use this? I think this is a breaking change, and it won't be easy to resolve :(
We may need a systemd-fixup task in the CLI that fixes it somehow when an admin notices etc.

# ls -la /etc/systemd/system/dirsrv.target.wants
total 16
drwxr-xr-x. 1 root root 4096 Aug 11 06:24 .
drwxr-xr-x. 1 root root 4096 Aug  9 06:10 ..
lrwxrwxrwx. 1 root root   39 Aug 11 06:24 dirsrv@server.service -> /usr/lib/systemd/system/dirsrv@.service
# rpm -qf /usr/lib/systemd/system/dirsrv@.service
389-ds-base-1.4.0.13-1.fc28.x86_64

It's a symlink, that belongs to our rpm package. Whatever we change in our service file will be reflected in the existing installations.

It's just a mess to see a change like this being pushed on us :(

It's not a sudden change. .include directive was deprecated for a long time (few years now?) and was removed from documentation. systemd started to actively mention this in the logs since https://github.com/systemd/systemd/commit/41b283d0f1f4abd85d0bbeeb7f71bb30f87cfab9 which was committed in February.

I just found that this crept in RHEL8 Beta.

Currently /etc/sysconfig/dirsrv.systemd contains the following options: https://pagure.io/389-ds-base/blob/master/f/wrappers/systemd.template.sysconfig
But the values that we provide
1. Are lower than the defaults:

# systemctl show dirsrv  | grep 'LimitCORE\|LimitNOFILE'
LimitCORE=infinity
LimitCORESoft=infinity
LimitNOFILE=1048576
LimitNOFILESoft=1048576

While in config we have LimitCore=68719476736 and LimitNOFILE=16384
2. They are not taken into account at all. The output above was taken from F29 and RHEL8.

File /etc/sysconfig/dirsrv.systemd contains other useful options that the users might adjust, but they are commented out.
I propose to :
1. Move /etc/sysconfig/dirsrv.systemd to drop-in config file [1] under /etc/systemd/system/dirsrv\@.service.d/
See dnf provides "/etc/systemd/system/*.service.d/*conf" for the examples how other packages configure their limits.
2. Comment out LimitCore and LimitNOFILE since system defaults are more sane now.

Thoughts?

[1] https://www.freedesktop.org/software/systemd/man/systemd.unit.html

I agree with Viktor. We should move current file containing limits to the drop-in location. We can handle upgrades by ensuring the file is where it should be, and by ensuring the .include is not in the .service file, in a SPEC file scriptlet. And given the infinity defaults, we can comment these out as suggested.

I agree with Viktor. We should move current file containing limits to the drop-in location. We can handle upgrades by ensuring the file is where it should be, and by ensuring the .include is not in the .service file, in a SPEC file scriptlet. And given the infinity defaults, we can comment these out as suggested.

@mhonek, yeah works for me, would you like to work on this one? If so please assign it to yourself. Thanks!

@mhonek looks like we are getting some community pressure to get this fixed upstream. Are you still working on it?

We should retain LimitNOFILE in these files.

Additionally, if we change /etc/sysconfig we need to maek sure lib389 is changed to detect instances by looking for /etc/dirsrv/slapd-instance/dse.ldif or a similar marker.

https://pagure.io/389-ds-base/issue/50208

Does this also mean we should stop writing out the /etc/sysconfig file? I'm worried this change will trash every freeipa instance in a single fell swoop, as we'll break the krb ccache environment variable ....

Okay, for now as part of https://pagure.io/389-ds-base/issue/50208 I'm going to make lib389 stop writing the /etc/sysconfig file, and I will ask @cheimes to review the ipa installer and how they are writing the krb5 ccache env vars to make sure this works properly.

IPA code contains references to three sysconfig files:

    SYSCONFIG_DIRSRV = "/etc/sysconfig/dirsrv"
    SYSCONFIG_DIRSRV_INSTANCE = "/etc/sysconfig/dirsrv-%s"
    SYSCONFIG_DIRSRV_SYSTEMD = "/etc/sysconfig/dirsrv.systemd"

• SYSCONFIG_DIRSRV_SYSTEMD is only defined by no longer used in any code.
• SYSCONFIG_DIRSRV_INSTANCE is only used in backup and restore code
• SYSCONFIG_DIRSRV is modified to set KRB5_KTNAME env var

I was worried that would be the case where KRB5_KTNAME is set via env. We'll need to have a way to migrate that somehow in ipa I think if we are going to stop writing out the sysconfig file on future installs.

@mhonek, what is the status of this bug? Ticket 50208 was merged so can we proceed on this bug?

Commit 10bffac relates to this ticket

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/2934

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.