Despite our best efforts with testing , sometimes the Trisul-Probes can stop for a number of reasons. This document describes how you can debug such events.
If you find Trisul Probe has crashed, you can collect the following information before restarting. If nothing jumps out , you can contact Trisul Support and send us the logs.
The log files on the trisul probe are stored under /usr/local/var/log/trisul-probe/domain0/probe0/context0 The latest ns-xxx.log contains the most recent logs before the crash. You can also use the trisbashrc bash aliases to navigate the directories as shown below:
# add the helper aliases source /usr/local/share/trisul-probe/trisbashrc # to change to probe log dir cd.l # to tailf probe log file tailf.ns # the latest log file cd.l ls -lrt ns*
When contacting Trisul Support send us the latest log file ns-xxx.log
Sometimes useful clues can be found in the kernel message log. For example, when trisul is stopped by an OOM - Out of Memory killer. To view dmesg output
# to dump the kernel message log dmesg -T # to view trisul messages dmesg -T | grep trisul
To get probe version trisul –version
To get platform version uname -a
To get installed packages on probe
# on ubuntu dpkg -l | grep trisul # on centos rpm -qa | grep trisul
If we find nothing in the Trisul and Kernel log files, we (Trisul Support) will send you a special binary image with symbols. You can then run it under gdb to help pinpoint the location of the crash. This could be a bug
# install gdb
apt install gdb
# run the special trisul binary we send you like this
gdb --args /home/mike3/trisul -nodemon \
/usr/local/etc/trisul-probe/domain0/probe0/context0/trisulProbeConfig.xml \
-mode online_rxring
(...wait...)
# after it crashes - type bt on the gdb prompt
gdb: bt
..output here.. send us this output