On Wed, Sep 19, 2018 at 10:31:42AM +0000, Aaron A. Glenn wrote:
> * Claudio Jeker <[email protected]> [2018-09-19 09:15]:
> > On Tue, Sep 18, 2018 at 07:12:39PM +0000, Aaron A. Glenn wrote:
> > >
> > > Sep 18 19:06:10 nairobi bgpd[92056]: startup
> > > Sep 18 19:06:10 nairobi bgpd[92056]: rereading config
> > > Sep 18 19:06:10 nairobi bgpd[97583]: route decision engine ready
> > > Sep 18 19:06:10 nairobi bgpd[99160]: session engine ready
> > > Sep 18 19:06:10 nairobi bgpd[99160]: listening on 0.0.0.0
> > > Sep 18 19:06:10 nairobi bgpd[99160]: listening on ::
> > > Sep 18 19:06:10 nairobi bgpd[99160]: SE reconfigured
> > > Sep 18 19:06:10 nairobi bgpd[99160]: neighbor 2xxxx:xxxx::4 (nbo-v6):
> > > state change None -> Idle, reason: None
> > > Sep 18 19:06:10 nairobi bgpd[99160]: neighbor 2xxxx:xxxx::4 (nbo-v6):
> > > state change Idle -> Connect, reason: Start
> > > Sep 18 19:06:10 nairobi bgpd[97583]: change to/from route-collector mode
> > > ignored
> > > Sep 18 19:06:10 nairobi bgpd[97583]: RDE reconfigured
> > > Sep 18 19:06:10 nairobi bgpd[97583]: running softreconfig in
> > > Sep 18 19:06:10 nairobi bgpd[99160]: neighbor 2xxxx:xxxx::4 (nbo-v6):
> > > state change Connect -> OpenSent, reason: Connection opened
> > > Sep 18 19:06:10 nairobi bgpd[97583]: RDE soft reconfiguration done
> > > Sep 18 19:06:10 nairobi bgpd[99160]: neighbor 2xxxx:xxxx::4 (nbo-v6):
> > > state change OpenSent -> OpenConfirm, reason: OPEN message received
> > > Sep 18 19:06:10 nairobi bgpd[99160]: neighbor 2xxxx:xxxx::4 (nbo-v6):
> > > state change OpenConfirm -> Established, reason: KEEPALIVE message
> > > received
> > > Sep 18 19:06:10 nairobi bgpd[97583]: neighbor 2xxxx:xxxx::4 (nbo-v6):
> > > sending IPv6 unicast EOR marker
> > > Sep 18 19:06:12 nairobi bgpd[97583]: neighbor 2xxxx:xxxx::4 (nbo-v6): bad
> > > ASPATH, path invalidated and prefix withdrawn
> > > Sep 18 19:06:12 nairobi last message repeated 157 times
> > > Sep 18 19:06:12 nairobi bgpd[92056]: peer closed imsg connection
> > > Sep 18 19:06:12 nairobi bgpd[99160]: peer closed imsg connection
> > > Sep 18 19:06:12 nairobi bgpd[99160]: SE: Lost connection to RDE
> > > Sep 18 19:06:12 nairobi bgpd[99160]: peer closed imsg connection
> > > Sep 18 19:06:12 nairobi bgpd[99160]: SE: Lost connection to RDE control
> > > Sep 18 19:06:12 nairobi bgpd[92056]: main: Lost connection to RDE
> > > Sep 18 19:06:12 nairobi bgpd[92056]: session engine terminated; signal 11
> > > Sep 18 19:06:12 nairobi bgpd[92056]: route decision engine terminated;
> > > signal 11
> > > Sep 18 19:06:12 nairobi bgpd[92056]: terminating
> > >
> > >
> > >
> > > nairobi# sysctl kern.version
> > > kern.version=OpenBSD 6.4-beta (GENERIC.MP) #301: Tue Sep 18 08:25:16 MDT
> > > 2018
> > > [email protected]:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > >
> >
> > Can you try a later snapshot? The 9. Sept was right in the middle of n2k18
> > and it could be that this is just an unlucky snapshot with something that
> > is already fixed. If that does not help Stuart Henderson's mail has good
> > instructions.
>
> I initially experienced the behavior with a 9 Sept snapshot, and immediately
> re-deployed to the latest snapshot (18 Sept). Same result (bad ASPATH might be
> new, but don't quote me on that).
>
> > If you can get a backtrace for the RDE process crashing that would be
> > very helpful for me. One way of doing that is to attach gdb to the running
> > process or to get a core dump with kern.nosuidcoredump=3 set (and mkdir
> > /var/crash/bgpd)
>
> I'm unsure how to get a backtrace, short of finding the right breakpoint to
> set. Using all of my gdb knowledge, I set `follow-fork-mode child` and `catch
> fork` but, that wasn't very fruitful (especially w/o symbols)
Yes, the fork/exec of bgpd make it hard to start in gdb and switch to a
child. I think an easy option is to start bgpd and then attach gdb to the
RDE process.
/usr/sbin/bgpd -dvv
gdb /usr/sbin/bgpd -p `pgrep -f "bgpd: route"`
Then hit continue and wait.
It works best if used with a binary that has debug symbols.
> I will find time to follow sthens (wonderfully complete) instructions and/or
> make another attempt at getting a useful gdb backtrace after EuroBSDcon,
> provided the latest snapshot then exhibits similar behavior.
>
> Since it doesn't (seem to) coredump, I was unable to coax anything into
> /var/crash/bgpd
>
--
:wq Claudio
