unable to create a new list with stock install (UPDATE)

[acosnailman]

Hi All,

thanks for vicidial, it's great.

we use vicidial through a third party atm and i'd like to run our own box instead.
I'm proficient at the GUI side i'd say, and use it as a dialler manager. I do need to learn more about the carrier side of things.

I've installed and configured vicibox
VERSION: 2.12-538a
BUILD: 160122-1401

for testing purposes ONLY - it's running in a VM. I know it's not recommended and it will not be used here for production, i'm just trying to configure everything and see if I can migrate everything across before we do the real thing.
i've given the VM 16gb ram and 4 cores

My install is all stock
The issue at the moment is:
I can create users, create campaigns, configure carrier (showing registered in asterisk cli), but, i cannot create a new list.
When i try to create a list it just goes to the next page with the more verbose options but is missing the list name and description. no error is at the top.

When i try to connect to the database (disabled firewall) and try to view the vicidial_lists table i get -
[MySQL][ODBC 5.3(w) Driver][mysqld-5.5.5-10.0.21-MariaDB-log]Table './asterisk/vicidial_lists' is marked as crashed and last (automatic?) repair failed
The table "vicidial_lists" does not exist.
Unable to connect to the server "10.4.4.233". Check that the server is running and that you have access privileges to the requested database.

I am able to view vicidial_list and see the 7 leads setup by matt.

Any help greatly appreciated

[williamconley]

1) You missed your Vicibox Version and instead listed your ViciDIAL version (2.12-538a is the Vicidial version). Vicibox is the installer .iso (which provides the "Environment" for Vicidial), and the version of this is almost as important as the version of Vicidial. Try to always list both. For instance: Did you install with Vicibox 7.0.0 or 6.0.4?

2) Execute this to confirm your HD is not full (happens a lot on Virtual servers):

Code: Select all

df -h

3) Execute this to repair your list table specifically:

Code: Select all

mysqlcheck --auto-repair  --user=cron -p1234 asterisk vicidial_lists

4) Note that there's usually a reason for the failure such as:
* You shut down the server or MySQL abnormally (or there was a crash). MySQL does not like this. Avoid force shutdown (power switch). Use "shutdown -h -P now" at the CLI to shut off the server
* Too many lists (as in many millions?)
* Full HD (which is why we checked that in 2 above).

[acosnailman]

Hi William and thanks for the response.

1. Vicibox7

2. have 50gb free space.

3. This is the response for the command (tried without sudo just incase, looks like same result except says aborted at the end):

Code: Select all

vicibox7:~ # sudo mysqlcheck --auto-repair  --user=cron -p1234 asterisk vicidial_lists
Failed to SHOW CREATE TABLE `vicidial_lists`
Error: Table './asterisk/vicidial_lists' is marked as crashed and last (automatic?) repair failed
*** Error in `mysqlcheck': free(): invalid pointer: 0x00007ffc8f43c0f8 ***
======= Backtrace: =========
/lib64/libc.so.6(+0x727ff)[0x7f593b87a7ff]
/lib64/libc.so.6(+0x7806e)[0x7f593b88006e]
/lib64/libc.so.6(+0x78d86)[0x7f593b880d86]
mysqlcheck(+0x1d25f)[0x558f3fd2525f]
mysqlcheck(+0x1caa1)[0x558f3fd24aa1]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f593b829b05]
mysqlcheck(+0x1cbf2)[0x558f3fd24bf2]
======= Memory map: ========
558f3fd08000-558f3ffe1000 r-xp 00000000 08:02 649                        /usr/bin/mysqlcheck
558f401e1000-558f401e8000 r--p 002d9000 08:02 649                        /usr/bin/mysqlcheck
558f401e8000-558f4024e000 rw-p 002e0000 08:02 649                        /usr/bin/mysqlcheck
558f4024e000-558f40258000 rw-p 00000000 00:00 0
558f41962000-558f419a6000 rw-p 00000000 00:00 0                          [heap]
7f593b5f1000-7f593b607000 r-xp 00000000 08:02 655429                     /lib64/libgcc_s.so.1
7f593b607000-7f593b806000 ---p 00016000 08:02 655429                     /lib64/libgcc_s.so.1
7f593b806000-7f593b807000 r--p 00015000 08:02 655429                     /lib64/libgcc_s.so.1
7f593b807000-7f593b808000 rw-p 00016000 08:02 655429                     /lib64/libgcc_s.so.1
7f593b808000-7f593b9a6000 r-xp 00000000 08:02 655390                     /lib64/libc-2.19.so
7f593b9a6000-7f593bba5000 ---p 0019e000 08:02 655390                     /lib64/libc-2.19.so
7f593bba5000-7f593bba9000 r--p 0019d000 08:02 655390                     /lib64/libc-2.19.so
7f593bba9000-7f593bbab000 rw-p 001a1000 08:02 655390                     /lib64/libc-2.19.so
7f593bbab000-7f593bbaf000 rw-p 00000000 00:00 0
7f593bbaf000-7f593bcaf000 r-xp 00000000 08:02 655440                     /lib64/libm-2.19.so
7f593bcaf000-7f593beae000 ---p 00100000 08:02 655440                     /lib64/libm-2.19.so
7f593beae000-7f593beaf000 r--p 000ff000 08:02 655440                     /lib64/libm-2.19.so
7f593beaf000-7f593beb0000 rw-p 00100000 08:02 655440                     /lib64/libm-2.19.so
7f593beb0000-7f593beb3000 r-xp 00000000 08:02 655416                     /lib64/libdl-2.19.so
7f593beb3000-7f593c0b2000 ---p 00003000 08:02 655416                     /lib64/libdl-2.19.so
7f593c0b2000-7f593c0b3000 r--p 00002000 08:02 655416                     /lib64/libdl-2.19.so
7f593c0b3000-7f593c0b4000 rw-p 00003000 08:02 655416                     /lib64/libdl-2.19.so
7f593c0b4000-7f593c27c000 r-xp 00000000 08:02 655400                     /lib64/libcrypto.so.1.0.0
7f593c27c000-7f593c47c000 ---p 001c8000 08:02 655400                     /lib64/libcrypto.so.1.0.0
7f593c47c000-7f593c496000 r--p 001c8000 08:02 655400                     /lib64/libcrypto.so.1.0.0
7f593c496000-7f593c4a3000 rw-p 001e2000 08:02 655400                     /lib64/libcrypto.so.1.0.0
7f593c4a3000-7f593c4a7000 rw-p 00000000 00:00 0
7f593c4a7000-7f593c505000 r-xp 00000000 08:02 655489                     /lib64/libssl.so.1.0.0
7f593c505000-7f593c704000 ---p 0005e000 08:02 655489                     /lib64/libssl.so.1.0.0
7f593c704000-7f593c708000 r--p 0005d000 08:02 655489                     /lib64/libssl.so.1.0.0
7f593c708000-7f593c70f000 rw-p 00061000 08:02 655489                     /lib64/libssl.so.1.0.0
7f593c70f000-7f593c724000 r-xp 00000000 08:02 655505                     /lib64/libz.so.1.2.8
7f593c724000-7f593c923000 ---p 00015000 08:02 655505                     /lib64/libz.so.1.2.8
7f593c923000-7f593c924000 r--p 00014000 08:02 655505                     /lib64/libz.so.1.2.8
7f593c924000-7f593c925000 rw-p 00015000 08:02 655505                     /lib64/libz.so.1.2.8
7f593c925000-7f593c93d000 r-xp 00000000 08:02 655476                     /lib64/libpthread-2.19.so
7f593c93d000-7f593cb3c000 ---p 00018000 08:02 655476                     /lib64/libpthread-2.19.so
7f593cb3c000-7f593cb3d000 r--p 00017000 08:02 655476                     /lib64/libpthread-2.19.so
7f593cb3d000-7f593cb3e000 rw-p 00018000 08:02 655476                     /lib64/libpthread-2.19.so
7f593cb3e000-7f593cb42000 rw-p 00000000 00:00 0
7f593cb42000-7f593cb63000 r-xp 00000000 08:02 655374                     /lib64/ld-2.19.so
7f593ccdb000-7f593cd1a000 r--p 00000000 08:02 4362                       /usr/lib/locale/en_GB.utf8/LC_CTYPE
7f593cd1a000-7f593cd4f000 r--s 00000000 00:13 19008                      /run/nscd/services
7f593cd4f000-7f593cd54000 rw-p 00000000 00:00 0
7f593cd59000-7f593cd5a000 rw-p 00000000 00:00 0
7f593cd5a000-7f593cd61000 r--s 00000000 08:02 265425                     /usr/lib64/gconv/gconv-modules.cache
7f593cd61000-7f593cd62000 rw-p 00000000 00:00 0
7f593cd62000-7f593cd63000 r--p 00020000 08:02 655374                     /lib64/ld-2.19.so
7f593cd63000-7f593cd64000 rw-p 00021000 08:02 655374                     /lib64/ld-2.19.so
7f593cd64000-7f593cd65000 rw-p 00000000 00:00 0
7ffc8f41d000-7ffc8f43e000 rw-p 00000000 00:00 0                          [stack]
7ffc8f5dd000-7ffc8f5df000 r--p 00000000 00:00 0                          [vvar]
7ffc8f5df000-7ffc8f5e1000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]


4. i always shutdown with graceful guest shutdown/restart using vmware.
no lists atm at all (except maybe the stock one but i can't see it)

-

any other ideas?

[williamconley]

Error in `mysqlcheck': free(): invalid pointer:

I've never gotten this error. You'll need to look it up and find out what happened. Failing that, you could drop that table and re-create it from the appropriate sql fragment in the .sql script used to create it in the first place. This would be in /usr/src/astguiclient/trunk/extras

[acosnailman]

Error in `mysqlcheck': free(): invalid pointer:

I've never gotten this error. You'll need to look it up and find out what happened. Failing that, you could drop that table and re-create it from the appropriate sql fragment in the .sql script used to create it in the first place. This would be in /usr/src/astguiclient/trunk/extras

thanks, a little bit out of scope for me at this moment.

i just did a fresh install and all working

[acosnailman]

Strange -

new install worked fine for a time..

created list, added lead
changed and testing dialplan.. almost working except had some prefix issues..

then, without even restarting the server.. the campaign disappeared..
seems same problem - i connected with heidisql to check and i get the same error in there:

Code: Select all

/* Entering session "vicidial" */
USE `asterisk`;
SELECT `DEFAULT_COLLATION_NAME` FROM `information_schema`.`SCHEMATA` WHERE `SCHEMA_NAME`='asterisk';
SHOW TABLE STATUS FROM `asterisk`;
SHOW FUNCTION STATUS WHERE `Db`='asterisk';
SHOW PROCEDURE STATUS WHERE `Db`='asterisk';
SHOW TRIGGERS FROM `asterisk`;
SHOW EVENTS FROM `asterisk`;
/* SQL Error (1044): Access denied for user 'cron'@'%' to database 'asterisk' */
SHOW CREATE VIEW `asterisk`.`vicidial_campaigns`;
/* SQL Error (144): Table './asterisk/vicidial_campaigns' is marked as crashed and last (automatic?) repair failed */
SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA='asterisk' AND TABLE_NAME='vicidial_campaigns';
/* Access violation at address 0000000000A9BD1B in module 'heidisql.exe'. Read of address 0000000000000030 */
SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE   TABLE_NAME='vicidial_campaigns' AND TABLE_SCHEMA='asterisk';
SELECT CURRENT_USER();
SHOW CREATE VIEW `asterisk`.`vicidial_campaigns`;
/* SQL Error (144): Table './asterisk/vicidial_campaigns' is marked as crashed and last (automatic?) repair failed */
SELECT * FROM INFORMATION_SCHEMA.VIEWS WHERE TABLE_SCHEMA='asterisk' AND TABLE_NAME='vicidial_campaigns';
/* Access violation at address 0000000000A9BD1B in module 'heidisql.exe'. Read of address 0000000000000030 */
SELECT * FROM `asterisk`.`vicidial_campaigns` LIMIT 1000;
/* SQL Error (144): Table './asterisk/vicidial_campaigns' is marked as crashed and last (automatic?) repair failed */

[williamconley]

Heidisql? You're not checking this directly on the server? What if heidi is breaking things ...?

[acosnailman]

Heidisql? You're not checking this directly on the server? What if heidi is breaking things ...?

Hi thanks William,

I only checked with Heidi after the problem occurred

"campaign disappeared from agent drop down"
and "disappeared when logging in as admin and checking campaigns"

[williamconley]

From my point of observation:
1) I've never had this happen with any client
2) I've never used heidisql nor has any client

With that information ... I could assume that your earlier hookup of heidisql caused heidi to be able to go haywire and break something. The fact that I am unaware of heidi's activities of course leads me to this possibility.

Admittedly, we've also not begun to use Vicibox 7.0, so it could certainly be there as well.

Comes down to this question: Was heidi installed and connected to the server before the crash?

And of course my favorite question: Is this server Virtual?

Next possibility: Is the HD special in any way? (bad hd's cause issues ...)

[acosnailman]

From my point of observation:
1) I've never had this happen with any client
2) I've never used heidisql nor has any client

With that information ... I could assume that your earlier hookup of heidisql caused heidi to be able to go haywire and break something. The fact that I am unaware of heidi's activities of course leads me to this possibility.

Admittedly, we've also not begun to use Vicibox 7.0, so it could certainly be there as well.

Comes down to this question: Was heidi installed and connected to the server before the crash?

And of course my favorite question: Is this server Virtual?

Next possibility: Is the HD special in any way? (bad hd's cause issues ...)

thanks for the reply again.

regarding heidi, i only used it after the problem for a GUI view of the DB so i don't think it's related. I also use Heidi on our working 3rd party vicidial db.

it is a virtual server, but it's only for testing purposes before I go for a physical server. i'm just making sure i can configure it all.
I also run a few other things on the host without issues - ubuntu server, windows server, pfsense, and some other stuff

The HDs are SSDs (raid 1 on a dell server)

[williamconley]

If your server is virtual, you found your problem. What type of Virtual are you using? We use vSphere for sandbox/development servers and have very good luck with that (read as: NO issues as long as we stick to a single agent, single call) ... however, we have not yet installed Vicibox 7 on a vSphere server as yet.

[acosnailman]

If your server is virtual, you found your problem. What type of Virtual are you using? We use vSphere for sandbox/development servers and have very good luck with that (read as: NO issues as long as we stick to a single agent, single call) ... however, we have not yet installed Vicibox 7 on a vSphere server as yet.

Thanks,

yes vsphere (esxi 6.0)

I don't really believe this is the cuplrit for corrupted db? (single call as well). I can imagine their being performance issues but not this-- could be wrong though

maybe there is an issue with vicibox7?

[williamconley]

Possibly. We only use 6.0.4 (since we KNOW it works). And we are not yet on vSphere 6 (5.0 -> 5.5). But virtual servers are known for causing db corruption and other irregularities in underpowered servers. How many cores in the host and assigned to this server?

[acosnailman]

Possibly. We only use 6.0.4 (since we KNOW it works). And we are not yet on vSphere 6 (5.0 -> 5.5). But virtual servers are known for causing db corruption and other irregularities in underpowered servers. How many cores in the host and assigned to this server?

4 cores (server has 2x Hex core 2.9ghz - 12 in total)

everything seemed fast and no load on the server, the voice also sounded fine from the "you are the only person in this conference", if that means anything

[williamconley]

voice timing is not usually the issue. mysql and perl, however, often use more processor than it would seem. mysql because it's a db system and perl because hi-res timing is explicitly loaded.

however, based on your description, i'd suggest 6.0.4 vicibox to see if that resolves your issue. AFAIK, Vicibox 7 does not technically alter your Vicidial capabilities at this point, so dropping to 6.0.4 should not have any adverse affects, aside from the fact that it's well-tested and 7 is just recently past debugging.