hcidbdump -r -D -d threadname questions

[Gerand Fontenot]

I ran this command to clean out message for a certain thread that was no longer needed.  It had 100,000 messages in it.  When I ran the command the screen quit show me the messages so I then did a ctrl C.  This brought me back to the prompt but all my treads locked up I had to stop all processes, stop the deamons and delete the thread and save a new netconfig with out this tread.  After I did all of this then I was able to bring up the processes and threads again.  I have done the command before for less message and did not have this problem.   What did I do wrong and where are these 100,000 messages.  Can someone tell me what I should have done and is there a way for me to get rid of the 100,000 messages.     Thanks still learning

Topic

[Tom Rioux]

Gerand,

With 100,000 messages in the database, it will take a bit to delete them.  It may appear that your screen is locked up, but don’t get too anxious.  The command is still being executed in the background.   By hitting the ctrl-c, I’m surprised that it didn’t corrupt your database.  NEVER do a

ctrl-c while running an hcidbdump command.  Since you used the -D option, the messages would have been deleted.

Next time, just be patient.   Your prompt will come back without having to run the ctrl-c.  Just give the command time to execute.   The length of time depends on how many messages are in the database.

Hope this helps…

Tom Rioux

[Gerand Fontenot]

Thanks Tom

Does anyone know how I can delete the messages now that I have changed the config file.

Thanks

[Tom Rioux]

Are the 100,000 messages still in the database?  Since you deleted the outbound thread, try deleting the messages using the inbound thread, provided it is still there.  Use the following command to delete the unwanted messages:

hcidbdump -r -f -D

Is the inbound thread still there?  If so, MAKE SURE you take the inbound thread down before doing this and let the messages you do want pass through.  That way you don’t delete any good messages by mistake.

Hope this helps…

Tom Rioux

[David Teh]

Hi Gerand,

Like Thomas mentioned, ctrl-c is a major no-no.

However, if your config is such that the inbound thread has more than one outbound thread, you should not execute “hcidbdump -r -f -D”. Thomas is not exactly wrong, but we don’t have the full picture. 😛

I’ve done ‘hcidbdump -r -d -D’ before, but like Thomas mentioned, with large amount of messages, it will take forever…but it will get there….:)

By the way, did you stop-start the process of the inbound thread? Otherwise, the routing of the messages to the deleted thread will continue.

[Gerand Fontenot]

I ran command hcidbdump -r -d threadname | wc -l and I got a count of 46500 messages.  So I figured if it could count then it should be able to delete.  I then ran hcidbdump -r -D -d threadname and it worked.

But this time no control C.

Thanks for all your help

[Sam Craig]

We also use the -F flag at the end of the hcidbdump command.  Manual says this ….. -F deletes sent messages.

Command we normally use….hcidbdump -e -D -d thread_name

[Michael Hertel]

Another handy flag is U (username)

hcidbdump -r -D -U MIKE

This uses a different user name of your choice while running the command. This way if you do control-c, you don’t hose the engine’s TEST user name. If you control-c with user MIKE on accident, then use user JANE next time.

[Robert Kersemakers]

Ah Michael: you made my day!!

I hadn’t seen this option and have just implemented it in one of our ‘check’ scripts that we execute every morning to see if everything is running ok. Sometimes when an interface is down, the list of messages in the recovery database is enormous and you will almost automatically control-c to stop the list.

I now use this -U option to use a different user and also lmclear this user first when running the script. Works like a charm.

Thanks!!

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Russ Ross]

I want to add my thanks to Mike for sharing what I think will be an improvement over our currently required standard for doing backend hcidbdbump commands.

Little peices of saved greif really add up when you have a big multiplier (many sites and many interfaces).

MD Anderson Cancer Center currently has a required integration team standard that prohibits doing ctrl-c no matter how long you have to wait on hcidbdump but still happens sometimes.

Then we typically get out of it by doing

    lmclear -u TEST -mp

I like Mike’s approach much better because it never puts the TEST user at risk.

I’m going to present my interpretation seen below of Mike’s method for doing backend hcidbdump commands to our integration team and have them vote on it becoming our new required standard.

    lmclear -u RUSS -mp

    hcidbdump -r -U RUSS whatever_else

    ctrl-c or whatever_else

    lmclear -u RUSS -mp

Since everyone on our team has been burned by this from time to time, I think unanamous approval will be a slam dunk.

Russ Ross
RussRoss318@gmail.com

[Ed Mastascusa]

more on -U: If you embed the -U parameter into scripts you can still get user ID collisions when using constant strings. One way to minimize the chance of that is to use the process pid (ksh $$ variable or TCL “pid” command) as the User ID.

[Russ Ross]

I use $$ all the time for temp files to prevent collisions but this is another clever use that you pointed out, thanks.

Russ Ross
RussRoss318@gmail.com

[Author]

Replies