Your Session has been disabled.

[rahul jindal]

Dear All

We have a small call centre of 30 seats and have been using Vicidial from the past 1 year. From the past 1 month we have been facing a weird problem i.e. "Your session has been disabled". It appears in the middle of the call, when the agent is talking to the customer and the call gets hanged up. The problem is so erratic that at times it won't appear for 3-4 hrs continuously and at times it would start right after the agents log in.

The intensity of the problem reduces when only 4 agents are logged in and keeps increasing as the number of agents increases. The config of the dialer machine is as following:

1. Core II Duo Machine
2. VERSION: 2.2.1-237
3. BUILD: 100510-2015
4. Single Server
5. No Digium/Sangoma Hardware
6. No Extra Software After Installation

I have tried the following steps:
1. Reloaded the dialer
2. Changed the Internet Provider
3. Changed the wiring
4. Changed the operating system from linux to windows
5. Run different commands for repairing the asterisk or mysql, but it never shows any failure or corrupt file.

Any help or suggestions would be greatly appreciated.

Thanks

[williamconley]

Vicibox X.X from .iso | Vicidial X.X.X Build XXXX | Asterisk X.X.X | Single Server | No Digium/Sangoma Hardware | No Extra Software After Installation
___

describe the network: are the agents in the same physical location as the server?

ordinarily this occurs when there is network interference or a bandwidth limitation causing dropped packets from the agents to the server

the AJAX in the agent's web page loses contact with the server and the session is automatically disabled.

do the agent's workstations time sync to the same time source as the phone server?

what is your load during this time on the server?

how many calls (not just agents, but calls to agents and calls to prospects all together) and what codecs? are you recording all calls?

[rahul jindal]

Dear William

Thanks for the quick response. Please find the details as below:

describe the network: are the agents in the same physical location as the server?

Yes, both are at the same location.

ordinarily this occurs when there is network interference or a bandwidth limitation causing dropped packets from the agents to the server

We use Manageable switches with 1.5 MB bandwidth the only problem we see is that, the send and receive of agent PC shows millions of packet in both send and receive.

the AJAX in the agent's web page loses contact with the server and the session is automatically disabled.

How can we check it and rectify the same ?

do the agent's workstations time sync to the same time source as the phone server?

No, but since last 1 year, we have been using linux and the agent machines usually have different time as compared to dialer and used softphone like twinkle or eye beam. Also as a measure to solve this problem we installed Audio Codes (MP 124-FXS) recently but it didn't help.

what is your load during this time on the server?

0.89 to 1.20

how many calls (not just agents, but calls to agents and calls to prospects all together) and what codecs? are you recording all calls?

Our Dialer dials around ten thousand calls in a day with G729 Codec and yes we record all calls.


Also just to add, this problem usually occurs in long calls and slowly rises to even getting disabled at the time of an answering machines. At times it won't occur for 5-6hrs in between the calling hours and abruptly starts anytime. Basically has no set frequency of interval or duration and is very erratic.

[williamconley]

what is your load during this time on the server?

0.89 to 1.20

that's a heavy load for a dual core box. can you put a quad core in your motherboard?

between g729 and recording all calls, your system may be at its max limit.

how many calls (not just agents, but calls to agents and calls to prospects all together) and what codecs? are you recording all calls?

Our Dialer dials around ten thousand calls in a day with G729 Codec and yes we record all calls.

i was referring to simultaneous calls during the moment that the "failure" occurs (this is an indicator of load, if you find that the failure seems to occur only Above a certain number of simultaneous calls, you are reaching a barrier)

the AJAX in the agent's web page loses contact with the server and the session is automatically disabled.

How can we check it and rectify the same ?

your internal network speed should be MUCH faster than 1.5 M (it should be 100M or 1G to allow your agents to communicate with the server without interference).

usually occurs in long calls

you may want to look at time syncing all the agents computers (workstations) to the vicidial server. and ELIMINATE ANY NON-VICIDIAL traffic on the local network to maximize your usage.

[rahul jindal]

Dear William

I was using a quad core machine before and was facing the same problem. As a measure to solve this issue, we loaded vici on the Core II Duo. Also please see the system performance report for today:

---------- TOTALS, PEAKS and AVERAGES

Total Calls in/out on this server: 8035

Total Off-Hook time on this server (min): 2556.00

Average/Peak channels in use for server: 27.7889 / 62

Average/Peak load for server: 58.2201 / 204

Average USER process cpu percentage: 8.8938 %

Average SYSTEM process cpu percentage: 2.0259 %

Average IDLE process cpu percentage: 89.1103 %
-------------------------

Do you think it indicates any kind of problem ?

My internal LAN speed is 100Mbps and the predictive dialing ratio is usually 2. The problem occurs with 10 agents and even with 4 agents. This sort of problem was never faced by us before, even if 25 agents were sitting.

[williamconley]

number of agents can be an indication of load, but "number of simultaneous calls" including both agents and prospects (and prospects being dialed) can be a better indication of system usage than merely the number of agents (ie: 4 agents with a 10:1 ratio is a higher load than 10 agents with a 1:1 ratio).

so: how many simultaneous calls? (when the problem occurs). I note a "peak" of 62 ... how do you get to 62 simultaneous calls with 10 agents? Do you have sudden inrushes of inbound calls that overload your system?

If you say you "never faced this problem before" ... what changed?

New equipment? new network switch or router?

Your issue is (or will likely be found in) the communication between the agents and the server. Dropping packets is a bad thing.

Have you considered moving MySQL off the vicidial server onto another box, to reduce load? (remember to time sync the two servers! with ntp, not just a "command line momentary time check", but actually syncing the servers together).

[mflorell]

"Your session has been disabled" is a very specific message that means that the vicidial_live_agents record for the agent is gone.

We have not really experienced this as an issue with clients so I cannot begin to guess why it is happening in the way you describe.

[williamconley]

could this happen with "shared logins"? (I seem to recall this with a client)

[rahul jindal]

@ William

There is no inbound rush of calls, which is visible as we have simple outbound campaigns for UK and US, wherein we use vicidial.

Nothing was changed when this problem started occuring, we were using a quad core machine and everything was going smooth. Suddenly this problem started occuring, with a very low intensity and ignorable condition. But slowly it increased upto the current level of agents not being able to dial. As I mentioned earlier the problem is very erratic, which fails every logic. I've had days wherein the problem just didn't occur or only once or twice and the other days the problem just didn't stop, with no change at all.

New equipment was installed just to rectify this problem which majorly includes new set of parallel LAN wiring done, switching to managed switches from unmanaged and installation of Audiocode.

As you mentioned the communication between the agents and the server, to check that we had a constant ping from agent machine to server machine, when this problem occured, there was no lag or RTO in the ping. Kindly suggest if there is any other way which I can check the connectivity and packet drop between the agent and the server machine????

I have never before shifted MySQL to another machine, but if it can prove to be of help, I can change the same.

@ mflorell

I can understand, even I was unable to find any material regarding this problem in the forum, except for one in which the repair command sorted out the problem. That is why I started this discussion, mentioning my problem in detail for the opinions and suggestions from experts and professionals like you and William.

[williamconley]

have your network engineer check for packets dropping.

then you'll have to investigate the code, because matt says it is not related to my earlier assumption.

i was thinking of "time sync error" (ordinarily from dropped packets), but you are "paused", which is a different monkey entirely.

can you copy/paste the actual error?

you may need to investigate on your sql tables how the record for the agent(s) are being deleted, and then find out why the "situation" occurs that causes this phenomenon.

[rahul jindal]

William:

Network guys have tried "pathping" and used "ping test easy" software from the agent machine to server, but it doesn't show any packet loss not even 1%, when the dialing is going and the agent gets disabled screen.

Also when the screen of Your session has been disabled comes, it gives below 2 options i.e. Logout and Go Back. On clicking logout it gives "STILL ON A LIVE CALL!!! Hang it up then you can log out. 1" and Go Back doesn't work.

At the time of disabled the error which we get on CLI is "Conference number not found"

Also we have run different repair commands for sql or asterisk but it never shows any corrupted file.

[williamconley]

interesting concept. have you verified that all your conferences are listed in the GUI and in the .conf file?

i would consider an svn update to the latest version of vicidial for your branch (it may nip the problem in the bud, or it may have no effect, but it's certainly always worth the effort).

if all that fails, you'll be searching the code to find out what process did not find the conference room. then find out why.

[rahul jindal]

Yes we have verified that all conferences are listed in the GUI and in the .conf file.

We have the latest version of vicidial.

Another interesting thing happened, that calling was going on with the disabled problem, as soon as it started raining in here in the evening, the problem increased multifold. Can it be anything related to this ????

Also one unexplainable thing which is happening is that now even when the agent is waiting for a call, the screen pops up with "Your session has been disabled". This has really zapped us as to what could be the reason that the dialer shows disabled even when the agent is not taking a call.

[williamconley]

how did you perform your installation again?

[rahul jindal]

.iso file burnt on a dvd and configured the minutes...

[williamconley]

there would not be a vicidialnow version associated with this mystical dvd burning process would there?

honestly, if you "reinstalled" i'd try vicibox this time to see if there's some weird compatibility thing goin on

no offense gardo! nothing "intended" by that, just a troubleshooting tool. in fact i've used vicidialNOW to find a couple flaws that were distro related the other way as well (back in the good old Ubuntu days )

[rahul jindal]

William as you can figure out I am not a pro in vicidial, thats why unable to find out the solution of this unexplainable problem.

However as you asked, on the admin screen it shows VERSION: 2.2.1-237 / BUILD: 100510-2015.

About vicibox, I really dont know much about it but if you want I can try with it....is it similar like vicidial ?

Also just out of curosity, can electricity voltage fluctuations cause the dialer or the agent machine to behave strange ?

[williamconley]

William as you can figure out I am not a pro in vicidial, thats why unable to find out the solution of this unexplainable problem.

Not related to vicidial: the disk you burned from an .iso had a VERSION NUMBER of the .iso that you downloaded. Listing that version number would be the "Version of the installer software".

About vicibox, I really dont know much about it but if you want I can try with it....is it similar like vicidial ?

VICIdial = the software that is installed by VicidialNOW (along with an operating system called CentOS)
VICIdial = the software that is installed by ViciBox (along with an operating system called OpenSUSE)

The primary difference between the two "installers" is that one is CentOS and one is OpenSUSE (worthy of note however: ViciBox is supported by The Vicidial Group, whereas VicidialNOW is supported by Gardo). Otherwise they are the same from the standpoint of how it works after installation.

Also just out of curosity, can electricity voltage fluctuations cause the dialer or the agent machine to behave strange ?

Yep. You must have a UPS to protect the system or you will experience nasty behavior. Power outages are NOT good at all for a Vicidial system.

So please post the "Version" of the installer on your future posts (it helps users of the same installer and it helps the creators of the installers to find flaws and "situations" that occur with their respective distros).

[rahul jindal]

Hi William

Apology for the delayed response. The version is C 1.3.

Also a certain kind of pattern has been noticed that the dialer usually works fine without any problem or very less problem during the end hours of shift and the problem is usually very high during the time the shift starts i.e in afternoon. I don't know if this means something or not, as we have not marked timings in the campaign setup.

[yogeshkamat]

I have recently joined the forum.
Is the problem still there????
We have been facing problems "your session has been disabled" for last 2 months.
Endpoints are analog. Extensions get registered with Audio Codes.

Following observations and steps have resolved this problem:

1. I have observed the vicidial_live_agents table in these situations is found corrupt.
Also this mostly is due to abrupt shutdown which leaves a few tables inconsistent and corrupt.
mysqlcheck -u 'username' -p -A --auto-repair

After this i have resolved this issue more than 5 times.
Kindly update.

Asterisk 1.2 on Fedora | Vicidial 2.0.5-174 BUILD: 90522-0506 | 1 Database Server, 3 Asterisk Servers | NO digium/sangoma hardware | AudioCodes FXS Gateway MP-124

[rahul jindal]

Thanks Yogesh

Our problem has resolved. However it was more of a malpractice....and not much of a technical issue.

[williamconley]

I have recently joined the forum.
Is the problem still there????
We have been facing problems "your session has been disabled" for last 2 months.
Endpoints are analog. Extensions get registered with Audio Codes.

Following observations and steps have resolved this problem:

1. I have observed the vicidial_live_agents table in these situations is found corrupt.
Also this mostly is due to abrupt shutdown which leaves a few tables inconsistent and corrupt.
mysqlcheck -u 'username' -p -A --auto-repair

After this i have resolved this issue more than 5 times.
Kindly update.

Asterisk 1.2 on Fedora | Vicidial 2.0.5-174 BUILD: 90522-0506 | 1 Database Server, 3 Asterisk Servers | NO digium/sangoma hardware | AudioCodes FXS Gateway MP-124

if your hard drive is over 90% full, begin deleting log files and recordings until you have MUCH more available, then begin backing up your data regularly (which deletes the mysql logs that also take up a lot of room) and consider turning off logging if your drive is too small to store them (or use the crontab entries to reduce the number of days of log retention).

if your drive is NOT over 90% full, consider replacing the hard drive immediately (corrupt tables generally only happen during power failure or drive space issues)

[btaveras]

ViciBox_v.7.x86_64-7.0.1 | Vicidial VERSION: 2.12-538a | Asterisk 11.21.0-vici | Single remote Server from hivelocity | No Digium/Sangoma Hardware | No Extra Software After Installation

Guys,

Yesterday I installed this version of vicidial and it works like a charm, but every 45-60 minutes it kicks my agents out from the dialer with the session has been disable!! I fix the problem with the /usr/bin/mysqlcheck -u root -A --auto-repair, but after a certain time it happens again, I dont have g729 codecs, the time with the agents computer and the dialer is the same, the version of the softphone that I use is 3cx version 6, I have 5 agents log in. I have check the forums and still no luck!!!

I had it installed in a vmware workstation and had the same situation and the I rent a server in hivelocity and I thought it was good but still the problem persists, the last change I did was modify the vicirecord.conf file to allow the recordings permissions and after that nothing else.

Any suggestions.

Txs

[williamconley]

If it's fixed via mysqlcheck, something is corrupting your database. If your installation is virtual, the solution is physical hardware (virtual gets overloaded easily, and overload can cause any form of failure ... including a corrupted database).

Of course, the HD being full will also corrupt the database. As can tables with excessive entries (over 20 million records in a log file on a heavy use system ... for instance).

Which table gets corrupted?

[btaveras]

The server is in a physical server. I cannot tell the mysql check goes fast. And when I go up they are all marking ok, I notice that is stays still in the vicidial agent log table and the vicidial lead log archive.

Just happend like 2 minutes ago

[williamconley]

1) does mysqlcheck fix the problem?

2) does mysqlcheck report broken tables being repaired after the primary check has completed (it would then repair those that are broken)?

3) you know you can scroll back to see if any were broken ... if you're logging directly in at the console, use ssh (putty from chiark) and set the scrollback to 20000 lines.

[btaveras]

== Spawn extension (default, 8600051, 1) exited non-zero on 'SIP/102-00002c0e'
[Mar 6 13:02:58] -- Executing [h@default:1] AGI("SIP/102-00002c0e", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Mar 6 13:02:58] -- <SIP/102-00002c0e>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Mar 6 13:02:58] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 6 13:02:58] -- Executing [55558600051@default:1] MeetMeAdmin("Local/55558600051@default-0000311d;2", "8600051,K") in new stack
[Mar 6 13:02:58] WARNING[14021][C-0000317c]: app_meetme.c:5053 admin_exec: Conference number '8600051' not found!
[Mar 6 13:02:58] -- Executing [55558600051@default:2] Hangup("Local/55558600051@default-0000311d;2", "") in new stack
[Mar 6 13:02:58] == Spawn extension (default, 55558600051, 2) exited non-zero on 'Local/55558600051@default-0000311d;2'
[Mar 6 13:02:58] -- Executing [h@default:1] AGI("Local/55558600051@default-0000311d;2", "agi://127.0.0.1:4577/call_log--HVcauses--PRI-----NODEBUG-----16---------------") in new stack
[Mar 6 13:02:58] -- <Local/55558600051@default-0000311d;2>AGI Script agi://127.0.0.1:4577/call_log--HVcauses ... ---------- completed, returning 0
[Mar 6 13:02:59] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 6 13:02:59] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 6 13:03:01] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 6 13:03:01] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 6 13:03:01] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 6 13:03:02] == Manager 'sendcron' logged on from 127.0.0.1
[Mar 6 13:03:02] == Using SIP RTP CoS mark 5
[Mar 6 13:03:02] == Manager 'sendcron' logged off from 127.0.0.1
[Mar 6 13:03:04] > Channel SIP/102-00002c0f was answered
[Mar 6 13:03:04] -- Executing [8600051@default:1] MeetMe("SIP/102-00002c0f", "8600051,F") in new stack
[Mar 6 13:03:04] == Parsing '/etc/asterisk/meetme.conf': Found
[Mar 6 13:03:04] == Parsing '/etc/asterisk/meetme-vicidial.conf': Found
[Mar 6 13:03:04] -- Created MeetMe conference 1023 for conference '8600051'
[Mar 6 13:03:04] -- <SIP/102-00002c0f> Playing 'conf-onlyperson.gsm' (language 'en')
[Mar 6 13:03:05] > 0x7f1590711720 -- Probation passed - setting RTP source address to 148.0.229.133:48328
[Mar 6 13:03:05] > 0x7f1590711720 -- Probation passed - setting RTP source address to 148.0.229.133:48328


It happened again this is what it gives me in the CLI and after I repair the mysql table all good it all good. has you see in the mysql repair everything says ok.

I Dont see any trouble or repairing anything but I have to this this every time it kick them out.

Txs

asterisk.audio_store_details OK
asterisk.call_log OK
asterisk.call_log_archive OK
asterisk.callcard_accounts OK
asterisk.callcard_accounts_details OK
asterisk.callcard_log OK
asterisk.conferences OK
asterisk.contact_information OK
asterisk.dialable_inventory_snapshots OK
asterisk.groups_alias OK
asterisk.inbound_email_attachments OK
asterisk.inbound_numbers OK
asterisk.live_channels
note : The storage engine for the table doesn't support check
asterisk.live_inbound OK
asterisk.live_inbound_log OK
asterisk.live_sip_channels
note : The storage engine for the table doesn't support check
asterisk.nanpa_prefix_exchanges_fast OK
asterisk.nanpa_prefix_exchanges_master OK
asterisk.nanpa_wired_to_wireless OK
asterisk.nanpa_wireless_to_wired OK
asterisk.park_log OK
asterisk.parked_channels
note : The storage engine for the table doesn't support check
asterisk.phone_favorites OK
asterisk.phones OK
asterisk.phones_alias OK
asterisk.recording_log OK
asterisk.routing_initiated_recordings OK
asterisk.server_performance OK
asterisk.server_updater
note : The storage engine for the table doesn't support check
asterisk.servers OK
asterisk.system_settings OK
asterisk.twoday_call_log OK
asterisk.twoday_recording_log OK
asterisk.twoday_vicidial_agent_log OK
asterisk.twoday_vicidial_closer_log OK
asterisk.twoday_vicidial_log OK
asterisk.twoday_vicidial_xfer_log OK
asterisk.user_call_log OK
asterisk.vicibox OK
asterisk.vicidial_admin_log OK
asterisk.vicidial_agent_log OK
asterisk.vicidial_agent_log_archive OK
asterisk.vicidial_agent_skip_log OK
asterisk.vicidial_agent_sph OK
asterisk.vicidial_ajax_log OK
asterisk.vicidial_amm_multi OK
asterisk.vicidial_api_log OK
asterisk.vicidial_api_log_archive OK
asterisk.vicidial_asterisk_output OK
asterisk.vicidial_auto_calls
note : The storage engine for the table doesn't support check
asterisk.vicidial_avatar_audio OK
asterisk.vicidial_avatars OK
asterisk.vicidial_call_menu OK
asterisk.vicidial_call_menu_options OK
asterisk.vicidial_call_notes OK
asterisk.vicidial_call_notes_archive OK
asterisk.vicidial_call_time_holidays OK
asterisk.vicidial_call_times OK
asterisk.vicidial_callbacks OK
asterisk.vicidial_callbacks_archive OK
asterisk.vicidial_campaign_agents OK
asterisk.vicidial_campaign_cid_areacodes OK
asterisk.vicidial_campaign_dnc OK
asterisk.vicidial_campaign_hotkeys OK
asterisk.vicidial_campaign_server_stats
note : The storage engine for the table doesn't support check
asterisk.vicidial_campaign_stats OK
asterisk.vicidial_campaign_stats_debug OK
asterisk.vicidial_campaign_statuses OK
asterisk.vicidial_campaigns OK
asterisk.vicidial_campaigns_list_mix OK
asterisk.vicidial_carrier_log OK
asterisk.vicidial_carrier_log_archive OK
asterisk.vicidial_chat_archive OK
asterisk.vicidial_chat_log OK
asterisk.vicidial_chat_log_archive OK
asterisk.vicidial_chat_participants OK
asterisk.vicidial_closer_log OK
asterisk.vicidial_closer_log_archive OK
asterisk.vicidial_comments OK
asterisk.vicidial_conf_templates OK
asterisk.vicidial_conferences OK
asterisk.vicidial_configuration OK
asterisk.vicidial_country_iso_tld OK
asterisk.vicidial_cpd_log OK
asterisk.vicidial_custom_cid OK
asterisk.vicidial_custom_leadloader_templates OK
asterisk.vicidial_custom_reports OK
asterisk.vicidial_daily_max_stats OK
asterisk.vicidial_daily_ra_stats OK
asterisk.vicidial_dial_log OK
asterisk.vicidial_dial_log_archive OK
asterisk.vicidial_did_agent_log OK
asterisk.vicidial_did_agent_log_archive OK
asterisk.vicidial_did_log OK
asterisk.vicidial_did_ra_extensions OK
asterisk.vicidial_dnc OK
asterisk.vicidial_dnc_log OK
asterisk.vicidial_dnccom_filter_log OK
asterisk.vicidial_drop_rate_groups OK
asterisk.vicidial_dtmf_log OK
asterisk.vicidial_email_accounts OK
asterisk.vicidial_email_list OK
asterisk.vicidial_email_log OK
asterisk.vicidial_extension_groups OK
asterisk.vicidial_filter_phone_groups OK
asterisk.vicidial_filter_phone_numbers OK
asterisk.vicidial_grab_call_log OK
asterisk.vicidial_hopper
note : The storage engine for the table doesn't support check
asterisk.vicidial_html_cache_stats OK
asterisk.vicidial_inbound_dids OK
asterisk.vicidial_inbound_group_agents OK
asterisk.vicidial_inbound_groups OK
asterisk.vicidial_ivr OK
asterisk.vicidial_language_phrases OK
asterisk.vicidial_languages OK
asterisk.vicidial_lead_filters OK
asterisk.vicidial_lead_recycle OK
asterisk.vicidial_lead_search_log OK
asterisk.vicidial_lead_search_log_archive OK
asterisk.vicidial_list OK
asterisk.vicidial_list_alt_phones OK
asterisk.vicidial_list_pins OK
asterisk.vicidial_list_update_log OK
asterisk.vicidial_lists OK
asterisk.vicidial_lists_custom OK
asterisk.vicidial_lists_fields OK
asterisk.vicidial_live_agents
warning : Table is marked as crashed and last repair failed
status : OK
asterisk.vicidial_live_chats OK
asterisk.vicidial_live_inbound_agents OK
asterisk.vicidial_log OK
asterisk.vicidial_log_archive OK
asterisk.vicidial_log_extended OK
asterisk.vicidial_log_extended_archive OK
asterisk.vicidial_log_noanswer OK
asterisk.vicidial_log_noanswer_archive OK
asterisk.vicidial_manager OK
asterisk.vicidial_manager_chat_log OK
asterisk.vicidial_manager_chat_log_archive OK
asterisk.vicidial_manager_chats OK
asterisk.vicidial_manager_chats_archive OK
asterisk.vicidial_manual_dial_queue OK
asterisk.vicidial_monitor_calls OK
asterisk.vicidial_monitor_log OK
asterisk.vicidial_music_on_hold OK
asterisk.vicidial_music_on_hold_files OK
asterisk.vicidial_nanpa_filter_log OK
asterisk.vicidial_nanpa_prefix_codes OK
asterisk.vicidial_outbound_ivr_log OK
asterisk.vicidial_outbound_ivr_log_archive OK
asterisk.vicidial_override_ids OK
asterisk.vicidial_pause_codes OK
asterisk.vicidial_phone_codes OK
asterisk.vicidial_postal_codes OK
asterisk.vicidial_process_trigger_log OK
asterisk.vicidial_process_triggers OK
asterisk.vicidial_qc_agent_log OK
asterisk.vicidial_qc_codes OK
asterisk.vicidial_recording_access_log OK
asterisk.vicidial_remote_agent_log OK
asterisk.vicidial_remote_agents OK
asterisk.vicidial_report_log OK
asterisk.vicidial_screen_labels OK
asterisk.vicidial_scripts OK
asterisk.vicidial_server_carriers OK
asterisk.vicidial_server_trunks OK
asterisk.vicidial_session_data OK
asterisk.vicidial_settings_containers OK
asterisk.vicidial_shifts OK
asterisk.vicidial_state_call_times OK
asterisk.vicidial_stations OK
asterisk.vicidial_status_categories OK
asterisk.vicidial_status_groups OK
asterisk.vicidial_statuses OK
asterisk.vicidial_territories OK
asterisk.vicidial_timeclock_audit_log OK
asterisk.vicidial_timeclock_log OK
asterisk.vicidial_timeclock_status OK
asterisk.vicidial_tts_prompts OK
asterisk.vicidial_url_log OK
asterisk.vicidial_url_multi OK
asterisk.vicidial_urls OK
asterisk.vicidial_user_closer_log OK
asterisk.vicidial_user_groups OK
asterisk.vicidial_user_log OK
asterisk.vicidial_user_territories OK
asterisk.vicidial_user_territory_log OK
asterisk.vicidial_users OK
asterisk.vicidial_voicemail OK
asterisk.vicidial_webservers OK
asterisk.vicidial_xfer_log OK
asterisk.vicidial_xfer_presets OK
asterisk.vicidial_xfer_stats OK
asterisk.vtiger_rank_data OK
asterisk.vtiger_rank_parameters OK
asterisk.vtiger_vicidial_roles OK
asterisk.web_client_sessions
note : The storage engine for the table doesn't support check
asterisk.www_phrases OK
mysql.column_stats OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.gtid_slave_pos OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.index_stats OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.roles_mapping OK
mysql.servers OK
mysql.table_stats OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK

[btaveras]

Guys

I am still facing the problem, I notice that is every hour!!, what can be the problem, any suggestions.

Txs

[mflorell]

Delete any .TMM files in your mysql data directory.

The reason this is happening every hour is probably because of a crontab entry script that is running at those times that is running a database query that is causing this issue indirectly.

[btaveras]

sorry the ignorance, but I dont know what are .TMM files in the sql server, what are those and how can I delete them from what DB or table?

Txs

[btaveras]

Ok, I find them:

./var/lib/mysql/asterisk/vicidial_live_agents.TMM
./var/lib/mysql/asterisk/vicidial_campaign_stats_debug.TMM

I deleted them, Ill let you know if the problem persists.

Txs

[btaveras]

Txs, that solve the issue.

Txs a lot team