Hi all, We've been having a few ldap timeouts and other weirdness. Unfortunately this has had the effect of stopping freeradius. The backtrace is below - any chance of someone taking a look and commenting? Thanks very much Andy rlm_ldap (ldap_sath): Deleting inviable connection (46672) Program received signal SIGPIPE, Broken pipe. 0x00007ffff6cdac3d in write () at ../sysdeps/unix/syscall-template.S:81 81 ../sysdeps/unix/syscall-template.S: No such file or directory. (gdb) bt #0 0x00007ffff6cdac3d in write () at ../sysdeps/unix/syscall-template.S:81 #1 0x00007fffef2a95e8 in ?? () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 #2 0x00007ffff1abade7 in ?? () from /usr/lib/x86_64-linux-gnu/libgnutls.so.26 #3 0x00007ffff1ab818c in gnutls_bye () from /usr/lib/x86_64-linux-gnu/libgnutls.so.26 #4 0x00007fffef4e8872 in ?? () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #5 0x00007fffef2aa762 in ber_int_sb_close () from /usr/lib/x86_64-linux-gnu/liblber-2.4.so.2 #6 0x00007fffef4d4072 in ldap_free_connection () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #7 0x00007fffef4cb747 in ldap_ld_free () from /usr/lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #8 0x00007fffef70ea49 in _mod_conn_free (conn=0x149bf90) at src/modules/rlm_ldap/ldap.c:1519 #9 0x00007ffff70f2d28 in ?? () from /usr/lib/x86_64-linux-gnu/libtalloc.so.2 #10 0x00007ffff70ef76b in _talloc_free () from /usr/lib/x86_64-linux-gnu/libtalloc.so.2 #11 0x00007ffff794f0b9 in _fr_trigger_talloc_ctx_free (trigger=0x13be190) at src/lib/misc.c:81 #12 0x00007ffff70f2d28 in ?? () from /usr/lib/x86_64-linux-gnu/libtalloc.so.2 #13 0x00007ffff70ef76b in _talloc_free () from /usr/lib/x86_64-linux-gnu/libtalloc.so.2 #14 0x00007ffff7b9dc21 in fr_connection_close_internal (pool=0x111d950, this=0x1427820) at src/main/connection.c:565 #15 0x00007ffff7b9f231 in fr_connection_reconnect (pool=0x111d950, conn=0x149bf90) at src/main/connection.c:1431 #16 0x00007fffef70d159 in rlm_ldap_search (result=0x7fffffffd130, inst=0xf23cb0, request=0x1430250, pconn=0x7fffffffd138, dn=0x144d5b0 "dc=SATH,dc=nhs,dc=uk", scope=2, filter=0x14e66c0 "sAMAccountName=2c1f23d63980", attrs=0x13964c0, serverctrls=0x0, clientctrls=0x0) at src/modules/rlm_ldap/ldap.c:973 #17 0x00007fffef706534 in ldap_xlat (out=0x7fffffffd1c0, outlen=2048, mod_inst=0xf23cb0, xlat_inst=0x0, request=0x1430250, fmt=0x15358e0 "ldaps:///dc=SATH,dc=nhs,dc=uk?description?sub?sAMAccountName=2c1f23d63980") at src/modules/rlm_ldap/rlm_ldap.c:323 #18 0x00007ffff7bc1771 in xlat_aprint (ctx=0x1430250, request=0x1430250, node=0x122f2f0, escape=0x0, escape_ctx=0x0, lvl=0) at src/main/xlat.c:2369 #19 0x00007ffff7bc1a64 in xlat_process (out=0x7fffffffd350, request=0x1430250, head=0x122f2f0, escape=0x0, escape_ctx=0x0) at src/main/xlat.c:2456 #20 0x00007ffff7bc1d6d in xlat_expand_struct (out=0x7fffffffd450, outlen=0, request=0x1430250, node=0x122f2f0, escape=0x0, escape_ctx=0x0) at src/main/xlat.c:2528 #21 0x00007ffff7bc22c5 in radius_axlat_struct (out=0x7fffffffd450, request=0x1430250, xlat=0x122f2f0, escape=0x0, ctx=0x0) at src/main/xlat.c:2676 #22 0x00007ffff7bab00e in map_to_vp (ctx=0x1430250, out=0x7fffffffd4e0, request=0x1430250, map=0x122e560, uctx=0x0) at src/main/map.c:821 #23 0x00007ffff7babfc6 in map_to_request (request=0x1430250, map=0x122e560, func=0x7ffff7baabe2 <map_to_vp>, ctx=0x0) at src/main/map.c:1141 #24 0x0000000000430eaa in modcall_update (request=0x1430250, stack=0x7fffffffd7d0, presult=0x7fffffffd770, priority=0x7fffffffd76c) at src/main/interpreter.c:587 #25 0x00000000004316c4 in modcall_recurse (request=0x1430250, stack=0x7fffffffd7d0, presult=0x7fffffffd7cc, ppriority=0x7fffffffd7c8) at src/main/interpreter.c:839 #26 0x0000000000431ad4 in modcall (component=MOD_AUTHORIZE, c=0x121ff10, request=0x1430250) at src/main/interpreter.c:1002 #27 0x0000000000427c2e in indexed_modcall (comp=MOD_AUTHORIZE, idx=0, request=0x1430250) at src/main/modules.c:977 #28 0x0000000000429dd0 in process_authorize (autz_type=0, request=0x1430250) at src/main/modules.c:2080 #29 0x000000000040f993 in rad_authenticate (request=0x1430250) at src/main/auth.c:435 #30 0x000000000043ad2b in request_running (request=0x1430250, action=1) at src/main/process.c:1482 #31 0x0000000000439a3f in request_queue_or_run (request=0x1430250, process=0x43abc9 <request_running>) at src/main/process.c:953 #32 0x000000000043b642 in request_receive (ctx=0x142feb0, listener=0xdd8620, packet=0x142ff10, client=0xdd3760, fun=0x40f6ee <rad_authenticate>) at src/main/process.c:1739 #33 0x00000000004199f9 in auth_socket_recv (listener=0xdd8620) at src/main/listen.c:1898 #34 0x00000000004427a9 in event_socket_handler (xel=0x13575d0, fd=13, ctx=0xdd8620) at src/main/process.c:4542 #35 0x00007ffff796ee5d in fr_event_loop (el=0x13575d0) at src/lib/event.c:637 #36 0x0000000000444694 in radius_event_process () at src/main/process.c:5585 #37 0x00000000004326ec in main (argc=2, argv=0x7fffffffe6a8) at src/main/radiusd.c:586 Unfortunately I need the process to carry on, so I can't debug any further (until the problem happens again). Hopefully the above will be sufficient for someone. Thanks Andy
On 22 Feb 2016, at 12:20, Franks Andy (IT Technical Architecture Manager) <Andy.Franks@sath.nhs.uk> wrote:
Hi all, We've been having a few ldap timeouts and other weirdness. Unfortunately this has had the effect of stopping freeradius. The backtrace is below - any chance of someone taking a look and commenting?
It's calling write on a socket that has already been closed. I pushed some changes which should show if we're closing the connection multiple times. Could you try with that? If it still crashes in the same way, then it's a libldap/gnutls issue. -Arran Arran Cudbard-Bell <a.cudbardb@freeradius.org> FreeRADIUS development team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2
participants (2)
-
Arran Cudbard-Bell -
Franks Andy (IT Technical Architecture Manager)