On 2019-03-03, Henry Bonath <[email protected]> wrote: > To elaborate, after enabling ldpd with -vvvv I have observed the > following in the log output: > > Mar 3 00:58:37 mpls-gw ldpd[77048]: nbr_fsm: event SESSION CLOSE > resulted in action CLOSE SESSION and changing state for lsr-id > 100.92.64.68 from OPERATIONAL to PRESENT > Mar 3 00:58:37 mpls-gw ldpd[77048]: session_close: closing session > with lsr-id 100.92.64.68 > Mar 3 00:58:37 mpls-gw ldpd[9902]: label decision engine exiting > Mar 3 00:58:37 mpls-gw ldpd[54245]: kernel routing table decoupled > Mar 3 00:58:37 mpls-gw ldpd[54245]: waiting for children to terminate > Mar 3 00:58:37 mpls-gw ldpd[54245]: ldp engine terminated; signal 10 > Mar 3 00:58:37 mpls-gw ldpd[54245]: terminating
A backtrace (preferably from a copy of ldpd built with debug symbols) would likely be helpful. If you don't already have the source tree checked out you can fetch just ldpd: $ cvs -d [email protected]:/cvs get -P -r OPENBSD_6_4 src/usr.sbin/ldpd $ cd src/usr.sbin/ldpd $ make obj && make clean && make DEBUG=-g Enable coredumps for priv-dropped processes, as shown in sysctl(8): # mkdir -m 700 /var/crash/ldpd # sysctl kern.nosuidcoredump=3 Then: # obj/ldpd -vvvvvd <wait for crash> # ls /var/crash/ldpd 12345.core # gdb obj/ldpd /var/crash/ldpd/12345.core (gdb) bt full
