Slapd-ltb service fails after server's reboot on RHEL8

[damiencassu]

Hello,

I recently noticed something strange after installing the latest 2.5.18 slapd-ltb rpms on a RHEL8 server.

Even if the slapd-ltb service is enabled in systemctl, the startup fails when the server starts up with the following error in slapd logs:

daemon: bind(7) failed errno=99 (Cannot assign requested address)

A simple attempt to start the slapd-ltb service (either with systemctl or with slapd-cli start) works perfectly.

It seems the process is starting too soon while the network services are not fully ready yet.

I've tuned a little bit the /usr/lib/systemd/system/slapd-ltb.service service file replacing

After=syslog.target network.target

by

After=syslog.target network-online.target

And now it works as expected.

• Is there a reason to not use network-online.target from the begining ?
• Are you aware of this issue on rhel8 (and maybe 9 ?) ? (I've tested it on rhel7 and the issue is not there)

Thanks a lot for your insights.
Have a nice weekend

Regards,

[davidcoutadeur]

Thanks for the bug report.

I did not face this issue before, but indeed it can be an improvement.

[davidcoutadeur]

Hello, after some investigations, it seems that:

• network-online.target is for software that really need a network communication up and ready
• network.target is sufficient for all others.

Actually, OpenLDAP does not need the connectivity, it just needs the network interface to exist.

As stated by systemd: (https://systemd.io/NETWORK_ONLINE/)

It is strongly recommended not to make use of this target (network-online.target) too liberally: for example network server software should generally not pull this in (since server software generally is happy to accept local connections even before any routable network interface is up). Its primary purpose is network client software that cannot operate without network.

If you check your network configuration, maybe you have a special configuration somewhere that prevent the needed network interfaces to show up? If you give more information or arguments, we can reconsider, but else I prefer not to change the current systemd configuration.

[damiencassu]

Hello, thanks for your feedback.

To my knowledge we do not have any specific network settings on our RHEL8 test server. I can try to run the same test on a vanilla CentOS 8 VM to check the behavior.

However I have done additional checks and :

1. With my current settings (where I have the issue), we are listening/binding on the server's hostname in /usr/local/openldap/etc/openldap/slapd-cli.conf so we have for instance IP="server.example.com"
2. Thus I wondered if the use of name resolution was part of an advanced network layer and thus not yet started when network.target fires up. I did another check but this time by using the server's IP with for instance IP="192.168.1.1" and the issue remains.
3. Finally I just restored the default /usr/local/openldap/etc/openldap/slapd-cli.conf values and started with IP="*" and this time no more issue.
   So it would mean that when we put an IP or a FQDN as a bind target, the slapd process needs more than just any interface but requires the one specified in its configuration to be available and crashes if not.

On you side did you managed to reporduce the issue on RHEL8 ?

Thanks a lot for your insights, I wish you a nice evening :)

[davidcoutadeur]

Hello,

This one clearly can be an issue : IP="server.example.com"

It should work with this one: IP="192.168.1.1". In theory, the interface behind 192.168.1.1 should be mounted at the time where slapd starts. Or maybe do you have a DHCP negociation that delays the interface to be up?

The problem with IP="*" is that at boot time, OpenLDAP will only bind to all detected interfaces at this point. (so probably 192.168.1.1 is not ready at this time)

On you side did you managed to reporduce the issue on RHEL8 ?

I don't have a RHEL8 + systemd available for this test, but I never had this issue before.

[damiencassu]

Hello,

Just checked to be sure : DHCP is disabled, the IP address value is hardcoded in the interface configuration file.

Duly noted for the IP="*"

Regards,