[quagga-dev 3065] reloading bgpd.conf

John Payne john at sackheads.org
Fri Apr 1 01:12:07 BST 2005


So, I had found that SIGHUP does reread the configuration, and most of 
the time it does NOT drop bgp sessions (regardless of the 
bgp_terminate() call).

My ongoing fight with bgpd "wedging" occasionally is now pointing me in 
the direction of my use of SIGHUP... as the last couple of times I've 
managed to attach to the "wedged" process, it's literally been stuck 
in:

#0  0x400e8d6a in free () from /lib/libc.so.6
#1  0x400e8ae3 in free () from /lib/libc.so.6
#2  0x080a3f9a in zfree (type=128, ptr=0x53569d00) at memory.c:99
#3  0x080848e8 in bgp_node_free (node=0x53569d00) at bgp_table.c:78
#4  0x08084f8d in bgp_node_delete (node=0x53569d00) at bgp_table.c:388
#5  0x08084fa7 in bgp_node_delete (node=0x53568038) at bgp_table.c:392
#6  0x08084b90 in bgp_unlock_node (node=0x53568038) at bgp_table.c:222
#7  0x08085090 in bgp_route_next (node=0x53568038) at bgp_table.c:441
#8  0x08063168 in bgp_clear_route_table (peer=0x82c3238, afi=1, safi=1 
'\001',
     table=0x82b8558) at bgp_route.c:1506
#9  0x080631d9 in bgp_clear_route (peer=0x82c3238, afi=1, safi=1 '\001')
     at bgp_route.c:1541
#10 0x0806328c in bgp_clear_route_all (peer=0x82c3238) at 
bgp_route.c:1557
#11 0x08057c9a in bgp_stop (peer=0x82c3238) at bgp_fsm.c:342
#12 0x08076c97 in bgp_write_notify (peer=0x82c3238) at bgp_packet.c:699
#13 0x0807717b in bgp_notify_send_with_data (peer=0x82c3238, code=6 
'\006',
     sub_code=3 '\003', data=0x0, datalen=0) at bgp_packet.c:860
#14 0x080771ba in bgp_notify_send (peer=0x82c3238, code=6 '\006',
     sub_code=3 '\003') at bgp_packet.c:867
#15 0x0805701b in bgp_terminate () at bgpd.c:4798
#16 0x0804ab2e in sighup () at bgp_main.c:171

The recent discussion on this list has pointed out that bgpd can get 
tied up with removing routes and not responding to keepalives due to 
its single threadedness... so I'm wondering if this is  related.

So... the short term question is how do I better reload a 
configuration?  These configs are changing many times a day, so 
stopping and restarting bgpd is *not* the right answer.

What purpose does bgp_terminate() serve in the SIGHUP handler?  Given 
that the "new" config is merged with the running one, to remove a 
neighbor, you'd have to do a "no neighbor xxx", so it can't be to 
pre-emptively clean up.   Is the answer as simple as removing the 
bgp_terminate() call?

In the SIGINT handler, bgp_terminate() is only called if the option not 
to retain routes is set, so I can't imagine that it would be dangerous 
to remove the call from sighup.




More information about the Quagga-dev mailing list