On 27 September 2013 12:42, Thomas Greer <[email protected]> wrote: > > > On 27/09/2013 11:30, "Mike Belopuhov" <[email protected]> wrote: > >>On 27 September 2013 12:21, Stuart Henderson <[email protected]> wrote: >>> On 2013/09/27 10:09, Thomas Greer wrote: >>>> Hi All >>>> >>>> I'm seeing high CPU usage with bgpd session engine, and this was >>>>knocking out >>>> all my routing. The only way to get routing back is to pill the bgpd >>>>and then >>>> start it again. sthen suggested I ktraced it and the output is below. >>> >>> To clarify from an IRC discussion (tgreer please correct me if I'm >>>wrong), >>> AIUI this was running OK until announcements are made on a particular >>>peer >>> session, just bringing the session up without making announcements >>>doesn't >>> trigger it. Same happens when either announcing just a default route or >>> when announcing full table. >>> >>> >>>> This is on 5.3 however same issues experienced on 5.2. Different >>>>hardware >>>> also. >>>> >>>> Peer is running bird. Versions: 1.3.8 and 1.3.11 >>>> >>>> Kdump: >>>> >>>> 6326 bgpd EMUL "native" >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>> >>> EAGAIN - send(2) says "The socket is marked non-blocking and the >>>requested >>> operation would block." >>> >>> Anyone have clues? >>> >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> 6326 bgpd CALL sendmsg(0x9,0x7f7ffffe7080,0) >>>> 6326 bgpd RET sendmsg -1 errno 35 Resource temporarily >>>>unavailable >>>> >> >>how was fd 0x9 obtained? > Not sure how to answer thisÅ does the info below help? This is taken > during it's 'broken' state >
in your kdump there was a syscall that returned it. like CALL socket RET 0x9 but your fstat output is sufficient as well for now. 0x9 is a unix stream socket. > _bgpd bgpd 5255 9* unix stream 0xffff800000ccf000 <-> > 0xffff800000ccfe00
