memory leak bird

[Network Administration]

   Date: Sun, 18 Jun 2000 11:55:54 -0700
   From: Florian Lohoff <flo at rfc822.org>
   Content-Type: text/plain; charset=us-ascii
   User-Agent: Mutt/1.0.1i
   Organization: rfc822 - pure communication
   Sender: owner-bird-users at atrey.karlin.mff.cuni.cz
   List-Help: <mailto:majordomo at atrey.karlin.mff.cuni.cz?body=help>
   List-Owner: <mailto:owner-bird-users at atrey.karlin.mff.cuni.cz>
   List-Post: <mailto:bird-users at atrey.karlin.mff.cuni.cz>
   List-Unsubscribe: <mailto:bird-users-request at atrey.karlin.mff.cuni.cz?body=unsubscribe>



   Hi,
   there is definitly a memory leak in Bird - After starting it uses
   approx 500K - After a couple of days we are running at ~30MB :)

   mgr1:~# ps auxw | grep bird
   root      1961  0.0 22.3 29556 28416 ?       S    Jun15   2:26 /usr/sbin/bird
   mgr1:~# date
   Sun Jun 18 18:03:49 UTC 2000

   This is only Rip, Direct, Kernel, Device


With the following config, bird has been running for 4 days, without
memory growth.  Linux kernel 2.2.14, Slackware 7.

# This pseudo-protocol performs synchronization between BIRD's routing
# tables and the kernel. If your kernel supports multiple routing tables
# (as Linux 2.2.x does), you can run multiple instances of the kernel
# protocol and synchronize different kernel tables with different BIRD tables.
protocol kernel {
        persist;                # Don't remove routes on bird shutdown
        scan time 60;           # Scan kernel routing table every N seconds
        export all;             # Default is export none
}

# This pseudo-protocol watches all interface up/down events.
protocol device {
        scan time 60;           # Scan interfaces every N seconds
}

# RIP aka Rest In Pieces...  Ignorance of most stub routers.
protocol rip  {
        interface "*" { mode broadcast; };
        import filter { print "importing"; accept; };
        export filter { print "exporting"; accept; };
}


Alas, it's also totally dead, as Ethereal shows a total absence of
routing packets.  Perhaps those broadcast addresses do need to be
explictly set....