Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#73008 - slapd (openldap-2.6.0-2): notification problems enforces service stop

Attached to Project: Arch Linux
Opened by Thomas Langen (langen) - Monday, 13 December 2021, 22:58 GMT
Last edited by Antonio Rojas (arojas) - Saturday, 08 January 2022, 17:32 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To Antonio Rojas (arojas)
Architecture x86_64
Severity Medium
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description: slapd from openldap-2.6.0-2 starts up but stops immediately, obviously because a notification is sent from some instance that is not allowed to do so (see "Got notification message from PID 25362, but reception only permitted for main PID 25361" in journalctl log).

Maybe is related to changing "Type=forking" in the [Service] section in /usr/lib/systemd/system/slapd.service for 2.4.59 to "Type=notify" for 2.6.0-2, but I do not really understand how that works.

Additional info:
* package: openldap-2.6.0-2 together with libldap-2.6.0-2
* packages *ldap-2.4.59-2* work fine

from journalctl (for broken 2.6.0-2):

Dez 02 10:48:19 lutz1 systemd[1]: Starting OpenLDAP Server Daemon...
Dez 02 10:48:19 lutz1 slapd[25361]: @(#) $OpenLDAP: slapd 2.6.0 (Nov 13 2021 17:37:14) $
Dez 02 10:48:19 lutz1 nslcd[1025]: [7b584f] <group/member="ldap"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Dez 02 10:48:19 lutz1 nslcd[1025]: [7b584f] <group/member="ldap"> no available LDAP server found: Server is unavailable: Resource temporarily unavailable
Dez 02 10:48:19 lutz1 systemd[1]: slapd.service: Got notification message from PID 25362, but reception only permitted for main PID 25361
Dez 02 10:48:19 lutz1 slapd[25362]: DIGEST-MD5 common mech free
Dez 02 10:48:19 lutz1 slapd[25362]: DIGEST-MD5 common mech free
Dez 02 10:48:19 lutz1 systemd[1]: slapd.service: Failed with result 'protocol'.
Dez 02 10:48:19 lutz1 systemd[1]: Failed to start OpenLDAP Server Daemon.
Dez 02 10:48:19 lutz1 audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 msg='unit=slapd comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=failed'

Steps to reproduce:

update openldap from 2.4.59-2 to 2.6.0-2 with pacman
This task depends upon

Closed by  Antonio Rojas (arojas)
Saturday, 08 January 2022, 17:32 GMT
Reason for closing:  None
Comment by loqs (loqs) - Tuesday, 14 December 2021, 00:07 GMT
If you modify slapd.service adding NotifyAccess=all does the service then start correctly?

The service file now comes from upstream [1] with a local modification to change the location to search for the environment file slapd.

[1] https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_6_0/servers/slapd/slapd.service
Comment by Thomas Langen (langen) - Tuesday, 14 December 2021, 09:18 GMT
No, unfortunately.

Setting NotifyAccess=all for 2.6 results in:

------------
kluge@lutz1 ~]$ sudo systemctl start slapd
sudo: ldap_sasl_bind_s(): Can't contact LDAP server
[kluge@lutz1 ~]$ sudo systemctl status slapd
sudo: ldap_sasl_bind_s(): Can't contact LDAP server
○ slapd.service - OpenLDAP Server Daemon
Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor pr>
Drop-In: /etc/systemd/system/slapd.service.d
└─override.conf
Active: inactive (dead) since Tue 2021-12-14 10:06:10 CET; 6s ago
Docs: man:slapd
man:slapd-config
man:slapd-mdb
Process: 64075 ExecStart=/usr/bin/slapd -u ldap -g ldap -h ldap://127.0.0.>;
Main PID: 64075 (code=exited, status=0/SUCCESS)
CPU: 27ms

Dez 14 10:06:10 lutz1 systemd[1]: Started OpenLDAP Server Daemon.
Dez 14 10:06:10 lutz1 slapd[64075]: @(#) $OpenLDAP: slapd 2.6.0 (Nov 13 2021 1>
openldap
Dez 14 10:06:10 lutz1 slapd[64076]: DIGEST-MD5 common mech free
Dez 14 10:06:10 lutz1 slapd[64076]: DIGEST-MD5 common mech free
Dez 14 10:06:10 lutz1 systemd[1]: slapd.service: Deactivated successfully.
------------

There is no further explanation visible why slapd was "Deactivated successfully".
Comment by Antonio Rojas (arojas) - Sunday, 19 December 2021, 11:12 GMT
George, can you take a look? Thanks
Comment by George Rawlinson (rawlinsong) - Wednesday, 22 December 2021, 02:41 GMT
Are you still encountering the bug, langen?

Are you able to do the following:

1. Backup your configuration (/etc/openldap) & data (/var/lib/openldap) to a separate directory.
2. Dump the database via slapcat/ldapadd/other tools.
3. Remove openldap via pacman, removing any orphaned directories (such as the ones mentioned in #1) and systemd service overrides.
4. Install 2.6.0-2, and restore the database from the dump (in #2 above).
Comment by Sascha P. (MrPeacock) - Thursday, 23 December 2021, 09:49 GMT
Same problem here. But if i start slapd manually /usr/bin/slapd -u ldap -g ldap -h ldaps://ldap.xxx.org:636 everythig is fine.

netstat -tulpn | grep 636
tcp 0 0 10.0.0.1:636 0.0.0.0:* LISTEN 125585/slapd
Comment by Francisco J. Vazquez (Fran) - Sunday, 02 January 2022, 09:57 GMT
FWIW, I had this same error. I though it was related to the PID message, but in my case that was a red herring. It was because I had /etc/systemd/system/slapd.service.d/override.conf with:

[Service]
ExecStart=
ExecStart=/usr/bin/slapd -u ldap -g ldap -h "ldaps:///"

because that was the previously recommended way to enable ldaps in the wiki (see https://web.archive.org/web/20210825133434/https://wiki.archlinux.org/title/OpenLDAP).

Now that part has been corrected. So I removed it, added a /etc/conf.d/slapd with:

SLAPD_URLS="ldaps:///"
SLAPD_OPTIONS=

and everything works as before with 2.6.0.
Comment by Sascha P. (MrPeacock) - Monday, 03 January 2022, 18:04 GMT
Thanks! Now it works as expected.
Comment by Antonio Rojas (arojas) - Thursday, 06 January 2022, 12:31 GMT
so can this be closed?
Comment by Thomas Langen (langen) - Saturday, 08 January 2022, 13:30 GMT
I guess it's ok now, and it can be closed. Thanks!

Loading...