I know there have been some blogs about the future design of bug-buddy. The current design has not been effective: When a program crashes it's very likely that users have lost work or time and they usually aren't very happy. They normally never go through the process of submitting bug reports and just want to get back to the software. So lots of useful information by hundreds of people is being lost and not getting back to the developers.
Bug-buddy needs a way for Admins to dump the information to a directory and hide the GUI from the users completely. It's my job to review them and get them submitted. I was happy to find that the hooks into bug-buddy from a crashing application are not deep, and that I could slip in my own script called bug-buddy to perform a fully automated dump.
If you want to get dumps from your users, the following simple script might be useful:
more /opt/gnome/bin/bug-buddy
#!/bin/ksh
#
# $1: Program that crashed
# $2: Process ID
# $3: Version Number
/opt/gnome/bin/zenity --info --text "Currently dumping crash information, Evolution will restart when finished" &
pid=`echo $2 | awk -F "=" ' {print $2}'`
prg=`echo $1 | awk -F "=" ' {print $2}'`
stamp=`date +%Y%m%d%H%M%S%N`
outfile="$prg.$stamp.$USER.txt"
/usr/bin/gdb -p $pid --eval-command="thread apply all bt" --batch --nw > /home/largo/tmp/evolution_crashes/$outfile
2 comments:
Haha, you still have Evolution hard coded in your zenity message. What a POS evo is eh?
The code looks worse than it really is. The server where this was implemented only runs Evolution. Nothing else is deployed or runs on that particular machine.
Evolution/email is absolutely the hardest thing to deploy in the enterprise because of the high level of customizations and the vastly different types of email that people receive.
Post a Comment