Re: keepalives (fwd)

[Gilad Arnold]

(I'm CC-ing a few lists, seems quite interesting IMO. Note: this refers 
to a post regarding bgpd becoming blocked on large output, eg "show ip 
bgp" -- see post to address@hidden by David G. Lawrence dated 14-Oct-03.)


Paul Jakma wrote:

> aha!
>
> i was right. i still cant quite see how though, as it does at least 
> seem to /try/ to not block.

Okay, I took a look again, it seems that it's a bit different from what 
we last discussed: this guy says he was using vtysh to control his bgpd; 
in this case, if you take a look at bgpd/bgp_route.c/bgp_show(), you'll 
see that there's no paging in case vty->type == VTY_SHELL_SERV (which I 
believe to be the case with vtysh, isn't it?). In this case, bgpd keeps 
dumping it's output lines into the vtysh fd, that is keep executing the 
output call chain, eg: bgpd/bgp_route.c/route_vty_out(), then 
lib/vty.c/vty_out(), note that for the vtysh case (vty_shell_serv()) it 
just uses write() calls into vty->fd! So, guess what, the unix socket is 
filled out pretty soon, and the write() call simply blocks!! Now, that's 
real process blocking, and is definitely a major flaw in bgpd design wrt 
vtysh interface.

My question here is: is this necessary for a daemon not to page output 
when working with vtysh? Hints: I can tell you the bgpd is the only 
daemon that checks for vty->type != VTY_SHELL_SERV when considering to 
page; we know that bgpd is the only daemon which is known to be blocked 
upon long output dumps. So, I'm not sure it's desirable practice here.

What do you think? Do you agree with the diagnosis?

Gilad