On Mon, 17 Aug 2026, Jose Asenjo via FreeIPA-users wrote:
hi,
our monitoring system warns us that some processes crash in our idm servers,
and when looking at it I see it's the ipa-otpd.
The idm servers run rhel 9.8
# systemctl list-units --state failed
● [email protected] loaded failed failed ipa-otpd service (PID
890225/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890222/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890222/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890225/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890225/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890222/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890222/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890224/UID 0)
● [email protected] loaded failed failed ipa-otpd service (PID
890222/UID 0
....
This list can grow infinitely. I can fix it temporarily using systemctl
reset-failed ipa-otpd*, but the failed services will start appearing as
soon as any user logs in with a passkey.
The login process works fine, by the way.
In the idm server I see this in the log files:
Aug 17 09:24:02 host systemd[1]: Started ipa-otpd service (PID 890225/UID 0).
Aug 17 09:24:02 host ipa-otpd[2202265]: LDAP:
ldapi://%2Frun%2Fslapd-realm-tld.socket
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: request received
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: user query start
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: user query end:
uid=username,cn=users,cn=accounts,dc=realm,dc=tld
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: passkey config
query start:
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: passkey query end:
ok
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: sent: 0 data: 309
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: ..sent: 309 data:
309
Aug 17 09:24:02 host ipa-otpd[2202265]: [email protected]: response sent:
Access-Challenge
Aug 17 09:24:02 host ipa-otpd[2202265]: Socket closed, shutting down...
Aug 17 09:24:02 host ipa-otpd[2202265]: malloc(): unsorted double linked list
corrupted
Aug 17 09:24:02 host systemd[1]: Started Process Core Dump (PID 2202266/UID 0).
Aug 17 09:24:02 host systemd-coredump[2202267]: Process 2202265 (ipa-otpd) of
user 0 dumped core.#012#012Stack trace of thread 2202265:#012#0
0x00007f4f0188d21c __pthread_kill_implemen
tation (libc.so.6 + 0x8d21c)#012#1 0x00007f4f0183fbb6 raise (libc.so.6 +
0x3fbb6)#012#2 0x00007f4f01829873 abort (libc.so.6 + 0x29873)#012#3
0x00007f4f0182a1b2 __libc_message.cold (libc.s
o.6 + 0x2a1b2)#012#4 0x00007f4f018972e7 malloc_printerr (libc.so.6 +
0x972e7)#012#5 0x00007f4f0189a2bc _int_malloc (libc.so.6 + 0x9a2bc)#012#6
0x00007f4f0189bdbe __libc_calloc (libc.so.6
0x9bdbe)#012#7 0x00007f4f021d3a4d ber_memcalloc_x (liblber.so.2 +
0x7a4d)#012#8 0x00007f4f021d3aa6 ber_alloc_t (liblber.so.2 + 0x7aa6)#012#9
0x00007f4f02251334 ldap_alloc_ber_with_optio
ns (libldap.so.2 + 0x26334)#012#10 0x00007f4f02248358 ldap_send_unbind
(libldap.so.2 + 0x1d358)#012#11 0x00007f4f02258d18 ldap_free_connection
(libldap.so.2 + 0x2dd18)#012#12 0x00007f4f0224e
7a7 ldap_ld_free (libldap.so.2 + 0x237a7)#012#13 0x00007f4f022b44fa verto_del
(libverto.so.1 + 0x44fa)#012#14 0x00007f4f022b461b verto_free (libverto.so.1 +
0x461b)#012#15 0x000055ce06e160d0
main (ipa-otpd + 0x40d0)#012#16 0x00007f4f0182a610 __libc_start_call_main
(libc.so.6 + 0x2a610)#012#17 0x00007f4f0182a6c0 __libc_start_main@@GLIBC_2.34
(libc.so.6 + 0x2a6c0)#012#18 0x000055
ce06e16385 _start (ipa-otpd + 0x4385)#012ELF object binary architecture: AMD
x86-64
Aug 17 09:24:02 host systemd[1]: [email protected]: Main process
exited, code=dumped, status=6/ABRT
Aug 17 09:24:02 host systemd[1]: [email protected]: Failed with
result 'core-dump'.
Aug 17 09:24:02 host systemd[1]: [email protected]:
Deactivated successfully.
The host has enough ram (1G free and nearly all its swap free too).
Logging in works so it's confusing. I could not find any such error in
the mailing list either.
Any ideas of why this service crashes?
Looks like a memory corruption within libldap code, probably due to how
ipa-otpd asynchronous calls drive it. Never saw that before.
Can you please open a ticket at
https://codeberg.org/freeipa/freeipa/issues with as much details
attached as possible?
--
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland
--
_______________________________________________
FreeIPA-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it:
https://forge.fedoraproject.org/infra/tickets/issues/new
