Browse KB by category:
Go to KB #:
BRU Server doesn't remain started or I'm getting a "gdbm fatal: read error" when BRU Server starts. What's causing this?
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:
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:
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.shTo execute that script and start repair process, perform the following steps:
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.