KB Logo

TOLIS Group Knowledge Base

Browse KB by category:
Go to KB #:
Email   Bookmark

BRU Server doesn't remain started or I'm getting a "gdbm fatal: read error" when BRU Server starts. What's causing this?

Views: 13940
Votes: 4
Posted: 26 Jun, 2007

If you've started the BRU Server Server daemon and found that it only starts for a few seconds, then quits, then you may be suffering from a "gdbm fatal: read error" on your BRU Server system.


The causes of this can be any one of the following:

  • You've moved your BRU Server installation from a Mac OS X machine to a Linux machine.
  • You've moved your BRU Server installation from a Linux machine to a Mac OS X machine.
  • You've moved your BRU Server installation from a Linux x86 machine to a Linux x86_64 machine.
  • You've moved your BRU Server installation from a Linux x86_64 machine to a Linux x86 machine.
  • One of the BRU Server gdbm datatables has become corrupt.

The first four possibilities are pretty self-explanatory.  In order to resolve any of the first four possibilities, please contact Technical Support for assistance in converting your BRU Server datatables.

The fifth possibility, gdbm file corruption, occurs from as many possibilities as there are computers in the world today.  It's completely unforeseen, nearly impossible to prevent, and even harder to correct without some type of data loss.  File corruption occurs from the deterioration of data as a result from an external source.  The corruption could be the result of the of hardware or software incompatibilities, failures or flaws.  The possibilities are not only computer system related, they can also be the result of power outages, dust, water, or extreme temperatures.  Natural disasters, such as electrical storms, thunder, and lightning can also be the culprit of how the data became corrupt.  If you do have a corrupt file, there's no way of saying for sure what actually caused the corruption.

Due to the inability to foresee data corruption on a system and to ensure that the BRU Server datatables are safe, a daily backup of the BRU Server environment is strongly recommended.  For information on how to do this, please refer to Appendix C of the BRU Server Admin Guide.

Recovering From a “gdbm fatal: read error” When Starting The BRU Server Server Daemon

During server daemon startup, if you are seeing an error message that states gdbm fatal: read error, and you have not moved the BRU Server environment from one OS to another (i.e.: OS X to Linux). This indicates that one (or more) of the gdbm datatables has become corrupted.

The following steps will allow you to determine which gdbm datatable file has become corrupt and will replace it allowing the server daemon to restart properly.  This script is was only designed to be run once!  Running this script more than one time will cause the erasing of good datatables. TOLIS Group is not responsible for any damage that this script may cause.  You should backup your BRU Server Server environment before you run this script.

To begin, create the following script as /usr/local/bru-server/fix-gdbm.sh or you my download the file:


# Copyright (C) 2006-2013 TOLIS Group, Inc. All rights reserved.

# TOLIS provides this script and assumes no responsibility
# for the content or operation in any particular environment.
# Further, TOLIS assumes no liability for potential harm or
# damage, software or hardware, that may result from the use of
# this script. The script are provided as-is only and may be
# modified for your use. VERIFY THE USEFULNESS of the script
# before you use it. The downloading and use of this script
# indicates that you have read and agree to these terms.

# This script will assist in finding the gdbm DB file(s) that are corrupt
# and causing a "gdbm fatal read error" when trying to start BRU Server.
# DO NOT RUN THIS SCRIPT MORE THAN ONCE! Doing so will cause good DB files
# to become erased. It is strongly advised that you backup your BRU Server
# Environment before troubleshooting the corrupt DB file.

# Do not change anything below unless you know #
# what you are doing! #


# Check if running as Root.
if [ "$UID " -ne "$ROOT_UID" ]; then
printf "\tMust be root (sudo) to run this script.\n"
printf "\tTry running this script with the 'sudo' command.\n"

if [ `pwd` != "$SERVERDIR" ]; then
printf "\tCannot change to $SERVERDIR.\n"
printf "\tTrying Mac OS X path...\n"
if [ `pwd` != "$FULLDIR_MAC" ]; then
printf "\tCannot change to $FULLDIR_MAC.\n"
printf "\tBRU Server install path cannot be found. Please check your installation\n"
printf "\tand make sure that this script is being run on the BRU Server Server system.\n"
printf "\n\tExiting script.\n"
exit $E_XCD

FILES1="archives backup dest devices drives history license"
FILES2="machines parm schedule tapes upstage user"

for DB in $FILES1 $FILES2
if [ ! -e "$DB.save" ]; then
mv $DB $DB.save
printf "\nThere is already a \"$DB.save\" file in the BRU Server directory.\n"
printf "Continuing with this script may erase good DB files.\n"
printf "Do you want to move the \"$DB.save\" file first? [N/y] "
if [ "$ANSWER" = "Y" -o "$ANSWER" = "y" ]; then
if [ ! -e "$DB.copy" ]; then
mv $DB.save $DB.copy
printf "\n\n==============================================================\n"
printf "There is already a \"$DB.save\" and \"$DB.copy\" DB file in the\n"
printf "BRU Server main directory. No modifications have been made to your\n"
printf "system at this time.\n"
printf "Please contact TOLIS Group Support for further assistance at\n"
printf "http://support.tolisgroup.com or 480-505-1814.\n"
printf "\nExiting script."
printf "\n==============================================================\n\n"
exit 1
printf "\nNo modifications have been made to your system.\n"
printf "Please move the \".save\" DB files to a safe location before\n"
printf "running this script again.\n\n"
printf "Exiting script now!\n"
exit 1

for DB in $FILES1 $FILES2
printf "\nTesting $DB database table file...\n"
printf "If BRU Server starts correctly, press CTRL-C to move to the next file.\n\n"
sleep 2
cp -f $DB.save $DB
./server --foreground
if [ "$?" -ne "0" ]; then
echo -ne "\a\nThe $DB file is corrupt - deleting...\n\n"
rm $DB

printf "\n\aBRU Server gdbm Database Fix Complete!\n\n"
sleep 2

exit 0

### EOF ###

This script will rename all of your existing datatables to protect them in preparation for testing each datatable to determine which is the corrupt table. Once saved, set its permissions to allow execution:

sudo chmod +x /usr/local/bru-server/fix-gdbm.sh
To execute that script and start repair process, perform the following steps:
sudo /usr/local/bru-server/fix_gdbm.sh

During the test, the name of each datatable file will be displayed, the file will be copied back to its original location, and the server daemon will be restarted. If the file is corrupt, you will receive the “gdbm fatal: read error” message and the server will exit. This will generate an error that the script recognizes and the file will be deleted. If the file is clean, the server will start properly and you will need to interact by pressing CTRL-C to move on to the next file.

Once the test completes, the corrupt file(s) will have been identified and a new datatable will be created to replace the corrupt file.

Once the corrupt file has been replaced, if you don't have a backup of that file or your BRU Server environment, then all of the data for that datatable will be lost.  If you find that you had multiple datatables that were corrupt, then all of the data contained within those datatables will be lost.  If this is the case, the remaining datatables will be copied back and the contents of those datatables will be viewable in the BRU Server Console .  To prevent datatable loss and to ensure that the BRU Server datatables are safe, a daily backup of the BRU Server environment is strongly recommended.  For information on how to do this, please refer to Appendix C of the BRU Server Admin Guide.

Others in this Category
document How can I test to see if my tape drive/library is operating properly under Mac OS X?
document What client system platforms are supported by BRU Server?
document Restoring from tape with BRU Server using the command line. How is this done?
document I have two NIC/Ethernet cards in my system, how do I tell BRU Server which one to use?
document SCSI Compatibility Issues Under Mac OS X
» More Articles

Powered by KnowledgebasePublisher
Page Load Time: 0.038598 seconds / 38.598 milliseconds.
Page File Size: 32341 bytes.