When starting freeswitch I get a long list of errors, starting from: 2010-08-04 21:24:01.608710 [INFO] switch_core_sqldb.c:1275 Opening DB 2010-08-04 21:24:01.611895 [ERR] switch_core_sqldb.c:404 SQL ERR [database disk image is malformed] drop table channels 2010-08-04 21:24:01.615011 [ERR] switch_core_sqldb.c:404 SQL ERR [database disk image is malformed] drop table calls 2010-08-04 21:24:01.617641 [ERR] switch_core_sqldb.c:404 SQL ERR [database disk image is malformed] drop table interfaces 2010-08-04 21:24:01.620330 [ERR] switch_core_sqldb.c:404 SQL ERR [database disk image is malformed] drop table tasks 2010-08-04 21:24:01.623370 [ERR] switch_core_sqldb.c:404 SQL ERR [database disk image is malformed] PRAGMA synchronous=OFF; 2010-08-04 21:24:01.626318 [ERR] switch_core_sqldb.c:404 SQL ERR [database disk image is malformed] PRAGMA cache_size=8000 2010-08-04 21:24:01.628830 [DEBUG] switch_core_sqldb.c:765 SQL ERR [database disk image is malformed] [select hostname from complete] Auto Generating Table! 2010-08-04 21:24:01.632166 [DEBUG] switch_core_sqldb.c:772 SQL ERR [database disk image is malformed] [CREATE TABLE complete ( sticky INTEGER, a1 VARCHAR(128), a2 VARCHAR(128), a3 VARCHAR(128), a4 VARCHAR(128), a5 VARCHAR(128), a6 VARCHAR(128), a7 VARCHAR(128), a8 VARCHAR(128), a9 VARCHAR(128), a10 VARCHAR(128), hostname VARCHAR(256) ); ] 2010-08-04 21:24:01.643766 [DEBUG] switch_core_sqldb.c:778 SQL ERR [database disk image is malformed] [CREATE TABLE complete ( sticky INTEGER, a1 VARCHAR(128), a2 VARCHAR(128), a3 VARCHAR(128), a4 VARCHAR(128), a5 VARCHAR(128), a6 VARCHAR(128), a7 VARCHAR(128), a8 VARCHAR(128), a9 VARCHAR(128), a10 VARCHAR(128), hostname VARCHAR(256) ); ] 2010-08-04 21:24:01.653300 [DEBUG] switch_core_sqldb.c:765 SQL ERR [database disk image is malformed] [select hostname from aliases] Auto Generating Table! [...] Which leads to two concerns: 1. Why is it trying to drop everything when the database is corrupt? (note: this is an older version now) 2. Which database is corrupt? Is there any command line tool I can use to verify it is corrupt? Or repair it even? Also not sure how it got to be corrupt in the first place. Might be something to do with a power failure. Freeswitch seemed OK, but I guess I should have checked the logs files at the time, the errors started about the same time. An automatic way of testing these files would be good, so I can ensure I am alerted if something goes wrong again. What is the best way to recover? -- Brian May <brian@microcomaustralia.com.au>
On 4 August 2010 21:35, Brian May <brian@microcomaustralia.com.au> wrote:
What is the best way to recover?
For now, to solve the immediate problem of "my phone doesn't work" I renamed my db directory to db.old, and let it recreate the files from scratch. Not sure, what if anything I have lost as a result - I guess the main concern would be the voicemail greeting messages - will they be ok, are are they referenced from the db files? Also still curious if there is a better way to recover, and/or find out which files in the db directory were corrupt, other then trial and error. -- Brian May <brian@microcomaustralia.com.au>
Well, you probably only have one file - core.db You shouldn't have lost anything important in there - it mostly just stored information on current calls, sip registrations that kind of thing. As for how to do sqlite data recovery, try googling. e.g. http://www.mail-archive.com/sqlite-users@sqlite.org/msg17538.html -Steve On 4 August 2010 12:42, Brian May <brian@microcomaustralia.com.au> wrote:
On 4 August 2010 21:35, Brian May <brian@microcomaustralia.com.au> wrote:
What is the best way to recover?
For now, to solve the immediate problem of "my phone doesn't work" I renamed my db directory to db.old, and let it recreate the files from scratch.
Not sure, what if anything I have lost as a result - I guess the main concern would be the voicemail greeting messages - will they be ok, are are they referenced from the db files?
Also still curious if there is a better way to recover, and/or find out which files in the db directory were corrupt, other then trial and error. -- Brian May <brian@microcomaustralia.com.au>
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 4 August 2010 22:28, Steven Ayre <steveayre@gmail.com> wrote:
Well, you probably only have one file - core.db
On my system I seem to have a number of db files: -rw-r--r-- 1 freeswitch daemon 14336 2010-08-04 21:37 call_limit.db -rw-r--r-- 1 freeswitch daemon 129024 2010-08-07 18:33 core.db -rw-r--r-- 1 freeswitch daemon 5120 2010-08-07 18:27 fifo.db -rw-r--r-- 1 freeswitch daemon 70656 2010-08-07 16:18 sofia_reg_external.db -rw-r--r-- 1 freeswitch daemon 1502208 2010-08-07 18:27 sofia_reg_internal.db -rw-r--r-- 1 freeswitch daemon 70656 2010-08-07 16:18 sofia_reg_internal-ipv6.db -rw-r--r-- 1 freeswitch daemon 14336 2010-08-04 21:43 voicemail_default.db
You shouldn't have lost anything important in there - it mostly just stored information on current calls, sip registrations that kind of thing.
Ok, good.
As for how to do sqlite data recovery, try googling. e.g. http://www.mail-archive.com/sqlite-users@sqlite.org/msg17538.html
Thanks for the reference. I tried looking but obviously wasn't looking for the right search term. -- Brian May <brian@microcomaustralia.com.au>
On 7 August 2010 18:35, Brian May <brian@microcomaustralia.com.au> wrote:
As for how to do sqlite data recovery, try googling. e.g. http://www.mail-archive.com/sqlite-users@sqlite.org/msg17538.html
Thanks for the reference. I tried looking but obviously wasn't looking for the right search term.
Curiously I had the same problem reoccur. Unfortunately freeswitch appears to work until some time after the initial problem, makes it hard to find out what happened. The power has failed recently though, maybe connected? [ etc ] 2010-08-17 04:30:40.728489 [CRIT] switch_core_sqldb.c:938 SQL thread unable to commit transaction, records lost! 2010-08-17 04:31:00.653705 [ERR] switch_core_sqldb.c:448 SQL ERR [database disk image is malformed] [ etc ] huey:/opt/freeswitch/db# ls -l core2.db -rw-r--r-- 1 freeswitch daemon 1502208 2010-08-15 17:11 core2.db huey:/opt/freeswitch/db# sqlite3 core2.db SQLite version 3.5.9 Enter ".help" for instructions sqlite> .dump BEGIN TRANSACTION; COMMIT; This is ext2 on flash memory. Maybe I should move core.db on to tmpfs? I get the impression persistence isn't required for this file... -- Brian May <brian@microcomaustralia.com.au>
"The power has failed recently though, maybe connected?" Quite likely. Anything in the disk write cache will be lost on a power failure. Two ways to avoid that are: 1) Battery backup for your RAID 2) Disable write cache (which will of course have a performance penalty) The database files would be actively changed, so any changes would be in the write cache resulting in a only partially written database when power returns. Note that each db file is a separate sqlite database. You will only need to repair/delete the damaged one(s). You might find that moving everything into a ODBC database with transaction support will result in less corruption if a power fails. -Steve On 18 August 2010 02:58, Brian May <brian@microcomaustralia.com.au> wrote:
On 7 August 2010 18:35, Brian May <brian@microcomaustralia.com.au> wrote:
As for how to do sqlite data recovery, try googling. e.g. http://www.mail-archive.com/sqlite-users@sqlite.org/msg17538.html
Thanks for the reference. I tried looking but obviously wasn't looking for the right search term.
Curiously I had the same problem reoccur. Unfortunately freeswitch appears to work until some time after the initial problem, makes it hard to find out what happened. The power has failed recently though, maybe connected?
[ etc ] 2010-08-17 04:30:40.728489 [CRIT] switch_core_sqldb.c:938 SQL thread unable to commit transaction, records lost! 2010-08-17 04:31:00.653705 [ERR] switch_core_sqldb.c:448 SQL ERR [database disk image is malformed] [ etc ]
huey:/opt/freeswitch/db# ls -l core2.db -rw-r--r-- 1 freeswitch daemon 1502208 2010-08-15 17:11 core2.db huey:/opt/freeswitch/db# sqlite3 core2.db SQLite version 3.5.9 Enter ".help" for instructions sqlite> .dump BEGIN TRANSACTION; COMMIT;
This is ext2 on flash memory. Maybe I should move core.db on to tmpfs? I get the impression persistence isn't required for this file... -- Brian May <brian@microcomaustralia.com.au>
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Oh, I didn't spot the ext2 mention... I guess this is an embedded system? The tmpfs option might work well, although it'll be all or nothing since everything is stored in the same directory. A symlink to a tmpfs mount probably wouldn't work as FS will try to create a new file in the db directory. -Steve On 18 August 2010 09:36, Steven Ayre <steveayre@gmail.com> wrote:
"The power has failed recently though, maybe connected?"
Quite likely. Anything in the disk write cache will be lost on a power failure. Two ways to avoid that are: 1) Battery backup for your RAID 2) Disable write cache (which will of course have a performance penalty)
The database files would be actively changed, so any changes would be in the write cache resulting in a only partially written database when power returns.
Note that each db file is a separate sqlite database. You will only need to repair/delete the damaged one(s).
You might find that moving everything into a ODBC database with transaction support will result in less corruption if a power fails.
-Steve
On 18 August 2010 02:58, Brian May <brian@microcomaustralia.com.au> wrote:
On 7 August 2010 18:35, Brian May <brian@microcomaustralia.com.au> wrote:
As for how to do sqlite data recovery, try googling. e.g. http://www.mail-archive.com/sqlite-users@sqlite.org/msg17538.html
Thanks for the reference. I tried looking but obviously wasn't looking for the right search term.
Curiously I had the same problem reoccur. Unfortunately freeswitch appears to work until some time after the initial problem, makes it hard to find out what happened. The power has failed recently though, maybe connected?
[ etc ] 2010-08-17 04:30:40.728489 [CRIT] switch_core_sqldb.c:938 SQL thread unable to commit transaction, records lost! 2010-08-17 04:31:00.653705 [ERR] switch_core_sqldb.c:448 SQL ERR [database disk image is malformed] [ etc ]
huey:/opt/freeswitch/db# ls -l core2.db -rw-r--r-- 1 freeswitch daemon 1502208 2010-08-15 17:11 core2.db huey:/opt/freeswitch/db# sqlite3 core2.db SQLite version 3.5.9 Enter ".help" for instructions sqlite> .dump BEGIN TRANSACTION; COMMIT;
This is ext2 on flash memory. Maybe I should move core.db on to tmpfs? I get the impression persistence isn't required for this file... -- Brian May <brian@microcomaustralia.com.au>
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 18 August 2010 18:38, Steven Ayre <steveayre@gmail.com> wrote:
Oh, I didn't spot the ext2 mention... I guess this is an embedded system?
Yes.
The tmpfs option might work well, although it'll be all or nothing since everything is stored in the same directory. A symlink to a tmpfs mount probably wouldn't work as FS will try to create a new file in the db directory.
Believe it or not, it seems to work, it seems to work. I created a dangling symlink to /tmp/core.db, and it put the file in the correct spot, under /tmp. Not sure if this is the best way or not... -- Brian May <brian@microcomaustralia.com.au>
Brian, I think there is a good reason to move your db/ dir to tmpfs. If you leave that on flash, you gonna do a lot of writes to the flash, and you could eventually wear it out if the box is installed for several years. How quick it could be worn out will depend on the quality of flash you put in that. David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34 Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. IPeva décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur. Le 18/08/2010 à 03:58, Brian May a écrit :
This is ext2 on flash memory. Maybe I should move core.db on to tmpfs? I get the impression persistence isn't required for this file... -- Brian May <brian@microcomaustralia.com.au>
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
On 18 August 2010 18:52, David Ponzone <david.ponzone@ipeva.fr> wrote:
I think there is a good reason to move your db/ dir to tmpfs. If you leave that on flash, you gonna do a lot of writes to the flash, and you could eventually wear it out if the box is installed for several years. How quick it could be worn out will depend on the quality of flash you put in that.
Yes, was thinking that too. However, I suspect I can't put voicemail_default.db onto tmpfs, I suspect that needs to have persistence - I assume it stores voicemail stuff not found anywhere else. Fortunately this file doesn't change often. -- Brian May <brian@microcomaustralia.com.au>
Checking the source code it contains two tables. One stores a list of voicemail messages including time, caller information and the location of the recorded voicemail file. The other stores the user preferences (password etc). I'd say both of those will want to be persistent. -Steve On 18 August 2010 10:32, Brian May <brian@microcomaustralia.com.au> wrote:
On 18 August 2010 18:52, David Ponzone <david.ponzone@ipeva.fr> wrote:
I think there is a good reason to move your db/ dir to tmpfs. If you leave that on flash, you gonna do a lot of writes to the flash, and you could eventually wear it out if the box is installed for several years. How quick it could be worn out will depend on the quality of flash you put in that.
Yes, was thinking that too.
However, I suspect I can't put voicemail_default.db onto tmpfs, I suspect that needs to have persistence - I assume it stores voicemail stuff not found anywhere else.
Fortunately this file doesn't change often. -- Brian May <brian@microcomaustralia.com.au>
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
participants (3)
-
Brian May
-
David Ponzone
-
Steven Ayre