Asterisk call_log table crashes daily
Posted:
Mon Oct 21, 2013 4:00 pm
by javad-afzal
Hi
as the subject shows, my asterisk call_log table crashes daily at about same time. don't know what is causing this, every time this happens i have to restart sql service and than repair call_log table. it doesn't even repair table without restarting sql service. every time i repair that table i get same errors and warning i.e
asterisk.call_log
Error : Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
Error : Table 'call_log' is marked as crashed and last (automatic?) repair failed
error : Corrupt
Repairing tables
asterisk.call_log
warning : Number of rows changed from 1040749 to 7275619
status : OK
HDD have 70 to 80% free disk space. system load is fine, load average: 0.64, 0.51, 0.42, unable to figure it out why is this happening on daily bases.
Thanks
ViciBox.i686-4.0.3.preload.iso | Vicidial 2.8-406a Build 130627-0745 | Asterisk 1.4.44-vici | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation
Re: Asterisk call_log table crashes daily
Posted:
Mon Oct 21, 2013 4:31 pm
by mflorell
Put this in the crontab on one of your servers to run at night,
### roll call_log and vicidial_log_extended daily on very high-volume dialing systems
20 1 * * * /usr/share/astguiclient/ADMIN_archive_log_tables.pl --daily
Re: Asterisk call_log table crashes daily
Posted:
Tue Oct 22, 2013 12:06 pm
by javad-afzal
Thanks, i will add this and let you know if this solved my issue. Thanks bro you guys have done great job with vicibox.
Re: Asterisk call_log table crashes daily
Posted:
Tue Oct 22, 2013 6:27 pm
by javad-afzal
Hi
i have tried editing the cronjobs, the entry you gave me was already there i removed the # from there made it active as you were suggesting, but table still crashed. predictive & manual dialing both don't work when this happens, below you can see the pattern for last four days for crashes.
ci-box:/var/log/mysql # cat mysqld.log | grep ERROR
131023 2:05:16 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
131023 2:05:30 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
131023 2:05:32 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
ci-box:/var/log/mysql # cat mysqld.log-20131022 | grep ERROR
131022 1:12:09 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
131022 1:12:22 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
131022 1:12:25 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
131022 1:12:26 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
ci-box:/var/log/mysql # cat mysqld.log-20131021 | grep ERROR
131021 1:06:24 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
ci-box:/var/log/mysql # cat mysqld.log-20131020 | grep ERROR
131020 1:40:43 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
131020 1:40:43 [ERROR] /usr/sbin/mysqld: Table './asterisk/call_log' is marked as crashed and last (automatic?) repair failed
Thanks
Re: Asterisk call_log table crashes daily
Posted:
Thu Oct 24, 2013 9:51 am
by lark
it seems after you modify your cron you mess it up
Re: Asterisk call_log table crashes daily
Posted:
Thu Oct 24, 2013 12:20 pm
by javad-afzal
My crontab
# DO NOT EDIT THIS FILE - edit the master and reinstall.
# (/tmp/crontab.Z9lMck installed on Tue Oct 22 23:32:50 2013)
# (Cronie version 4.2)
### keepalive script for astguiclient processes
* * * * * /usr/share/astguiclient/ADMIN_keepalive_ALL.pl
### remove old vicidial logs and asterisk logs more than 2 days old
28 0 * * * /usr/bin/find /var/log/astguiclient -maxdepth 1 -type f -mtime +2 -print | xargs rm -f
29 0 * * * /usr/bin/find /var/log/asterisk -maxdepth 3 -type f -mtime +2 -print | xargs rm -f
30 0 * * * /usr/bin/find / -maxdepth 1 -name "screenlog.0*" -mtime +4 -print | xargs rm -f
### fix the vicidial_agent_log once every hour and the full day run at night
33 * * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl
50 0 * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl --last-24hours
## uncomment below if using QueueMetrics
#*/5 * * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl --only-qm-live-call-check
### updater for VICIDIAL hopper
* * * * * /usr/share/astguiclient/AST_VDhopper.pl -q
### adjust the GMT offset for the leads in the vicidial_list table
1 1,7 * * * /usr/share/astguiclient/ADMIN_adjust_GMTnow_on_leads.pl --debug --list-settings
### optimize the database tables within the asterisk database
3 1 * * * /usr/share/astguiclient/AST_DB_optimize.pl
### VICIDIAL agent time log weekly and daily summary report generation
2 0 * * 0 /usr/share/astguiclient/AST_agent_week.pl
22 0 * * * /usr/share/astguiclient/AST_agent_day.pl
### VICIDIAL campaign export scripts (OPTIONAL)
#32 0 * * * /usr/share/astguiclient/AST_VDsales_export.pl
#42 0 * * * /usr/share/astguiclient/AST_sourceID_summary_export.pl
### inventory report optional
#1 7 * * * /usr/share/astguiclient/AST_dialer_inventory_snapshot.pl -q --override-24hours
### roll call_log and vicidial_log_extended daily on very high-volume dialing systems
20 1 * * * /usr/share/astguiclient/ADMIN_archive_log_tables.pl --daily
## uncomment below if using Vtiger
#1 1 * * * /usr/share/astguiclient/Vtiger_optimize_all_tables.pl --quiet
# cleanup of the scheduled callback records
25 0 * * * /usr/share/astguiclient/AST_DB_dead_cb_purge.pl --purge-non-cb -q
### inbound email parser should only be active on a single server
* * * * * /usr/share/astguiclient/AST_inbound_email_parser.pl### recording mixing/compressing/ftping scripts
#0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_mix.pl --MIX
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 * * * * /usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl
1,4,7,10,13,16,19,22,25,28,31,34,37,40,43,46,49,52,55,58 * * * * /usr/share/astguiclient/AST_CRON_audio_2_compress.pl --MP3
#2,5,8,11,14,17,20,23,26,29,32,35,38,41,44,47,50,53,56,59 * * * * /usr/share/astguiclient/AST_CRON_audio_3_ftp.pl --MP3
#0 1 * * * /usr/share/astguiclient/AST_CRON_audio_4_ftp2.pl --ftp-server=server.ip --ftp-login=user --ftp-pass=pass --ftp-directory=/ --ftp-persistent --ftp-validate --transfer-limit=100000 --list-limit=100000
### kill Hangup script for Asterisk updaters
* * * * * /usr/share/astguiclient/AST_manager_kill_hung_congested.pl
### updater for voicemail
* * * * * /usr/share/astguiclient/AST_vm_update.pl
### updater for conference validator
* * * * * /usr/share/astguiclient/AST_conf_update.pl
### flush queue DB table every hour for entries older than 1 hour
11 * * * * /usr/share/astguiclient/AST_flush_DBqueue.pl -q
### reset several temporary-info tables in the database
2 1 * * * /usr/share/astguiclient/AST_reset_mysql_vars.pl
### remove old recordings more than 7 days old, and delete originals after 1 day
#24 0 * * * /usr/bin/find /var/spool/asterisk/monitorDONE -maxdepth 2 -type f -mtime +7 -print | xargs rm -f
24 1 * * * /usr/bin/find /var/spool/asterisk/monitorDONE/ORIG -maxdepth 2 -type f -mtime +1 -print | xargs rm -f
### Reboot nightly to manage asterisk issues and memory leaks - uncomment if issues arise
#30 6 * * * /sbin/reboot
### remove text to speech file more than 4 days old
#20 0 * * * /usr/bin/find /var/lib/asterisk/sounds/tts/ -maxdepth 2 -type f -mtime +4 -print | xargs rm -f
Re: Asterisk call_log table crashes daily
Posted:
Fri Oct 25, 2013 4:23 am
by DomeDan
My guess: Faulty hardware.
* List the server hardware.
Also:
* Check the RAM, run memtest
* Check the harddrive, just a s.m.a.r.t. test to get some basic info might be enough.