Auto LogOFF

[circuit]

The agents logout exactly after 24 hours ? How to change the settings ? Is this a VICIDIAL setting or can it be a cron job scheduled ?

If a cron, which one could possibly be ?

Also, since this is on SUSE, where to find the cron log ?

[mflorell]

admin.php version and build?

Are you asking questions or making statements?

[circuit]

VERSION: 2.4-246
BUILD: 100317-1244


Definitely asking questions ..........

[circuit]

OK Adding to my previous post,

I am just trying to pick up which script causes the logout. Does it have to be a setting within the Admin interface OR it is scheduled by a cron ?

[mflorell]

is it the same time of day that this happens?

Have you looked in the crontab at that time?

[williamconley]

could you post your installation method?

And how do you mean "the agents log out"?

Can you be more specific regarding what --exactly-- happens?

[circuit]

The agents do not log out from asterisk. The call is connected. However, the web client interface logs out.

This happens exactly after 24 HRS.

First the agents get a message "session is paused". Then they log out from the web gui client.


Is this a vici setting, a cron ? I am still unable to make out.

This installation was remote from a developer. I am not sure as to what he has really done.

[circuit]

The agents logout everyday 1 AM, as if it is scripted or programmed. I am using multiple servers with load balancing..........

[circuit]

Which logs do I check to trace this out ?

[williamconley]

check crontab -e on all your machines to see if there is a 1AM process that may cause it.

do you reboot servers at 1AM?

when you say "exactly after 24 hrs" and then "everyday 1 AM" you are confusing me. have some agents log in at 2AM and see if it happens at 2AM the next morning or still at 1AM (in which case it has nothing to do with the hours since login, but is scripted to 1AM somewhere).

logs are in /var/log/astguiclient IF you have logging turned on to file under admin->servers->SERVERNAME. You can safely clean this folder out (remove all *.log entries) at 12:55AM and then sort through a much smaller pile of logs to find your problem at 1AM

[circuit]

Thank You William, That was a helpful response.

Yes, the problem occurs everyday at 1 AM.

The agents get a message of "Session is PAUSED" and they logout then.

They have to log in back then.

[williamconley]

Do you have any processes that run at 1AM? have you had any agents log out and back in at other times in the day to be sure that they, too, are still automatically logged out at 1AM?

If you have any 1AM processes, change them to 1:05; 1:10; 1:15 (staggered times) to allow you to narrow it down to ONE process.

[circuit]

OK, this is a production setup. I am reluctant to do any experimentation.

Yes, I have heard the agents saying that a similar issue comes up at 7AM, but by then are also logging out themselves, as the shift ends.

I am surely going to check if there is a cron that runs at 1 AM.

Do you have a quick command for that ?

[circuit]

Also, is it OK if I completely clean the log folder ?

I am going to empty the /var/log/astguiclient/

[circuit]

Here is the output of crontab -e

Code: Select all

### keepalive script for astguiclient processes
* * * * * /usr/share/astguiclient/ADMIN_keepalive_ALL.pl

### 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

### fix the vicidial_agent_log once every hour
#33 * * * * /usr/share/astguiclient/AST_cleanup_agent_log.pl

### 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 --postal-code-gmt

### reset several temporary-info tables in the database
2 1 * * * /usr/share/astguiclient/AST_reset_mysql_vars.pl

### optimize the database tables within the asterisk database
#3 1 * * * /usr/share/astguiclient/AST_DB_optimize.pl

### VICIDIAL agent time log weekly summary report generation
#2 0 * * 0 /usr/share/astguiclient/AST_agent_week.pl



[williamconley]

yes, cleaning out /var/log/astguiclient is safe (but just that directory, not the subdirectory "archive" which contains your BACKUPS which i'm SURE you make NIGHTLY ... riiiiiight? )

1 1,7 * * * /usr/share/astguiclient/ADMIN_adjust_GMTnow_on_leads.pl --debug --postal-code-gmt

this runs at 1:01AM and 7:01AM each morning. It can also be safely skipped for one day. Put a # in front of it for 24 hours if you want to test it (is NOT used at all during production)

There are others that run at various times. Anything that only runs once or twice a day you can safely change to a time when your server is NOT in use. (when is your server NOT in use?)

[circuit]

The agents still logged out although, I disabled that cron.

This should not be the one then.

I also ran it independently and still it caused no effects on the agent login.

[williamconley]

There are others that run at various times. Anything that only runs once or twice a day you can safely change to a time when your server is NOT in use. (when is your server NOT in use?)

[circuit]

Firstly, I'd like to thank you for your continuous assistance.

I am slightly confused with,

There are others that run at various times. Anything that only runs once or twice a day you can safely change to a time when your server is NOT in use. (when is your server NOT in use?)


Do you mean to say that there are other crons on other servers that may be executing? Yes, I do have 4 servers, it is multi-server environment. So, it may be running from other servers ?

But then, I had manually run the cron and it did not logged out the agents from the web gui (astguiclient)

Code: Select all

### 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 --postal-code-gmt


Also, I checked my system logs and here is what I found,

Code: Select all

Dec 16 01:00:01 vici1 /usr/sbin/cron[24236]: (root) CMD (/usr/share/astguiclient/AST_VDhopper.pl -q)
Dec 16 01:00:01 vici1 /usr/sbin/cron[24245]: (root) CMD (/usr/share/astguiclient/AST_manager_kill_hung_congested.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24249]: (root) CMD (/usr/share/astguiclient/ADMIN_keepalive_ALL.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24243]: (root) CMD (/usr/share/astguiclient/AST_vm_update.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24251]: (root) CMD (/usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24240]: (root) CMD (/usr/share/astguiclient/AST_conf_update.pl)
Dec 16 01:01:01 vici1 /usr/sbin/cron[24584]: (root) CMD (/usr/share/astguiclient/AST_conf_update.pl)
Dec 16 01:01:01 vici1 /usr/sbin/cron[24585]: (root) CMD (/usr/share/astguiclient/AST_VDhopper.pl -q)
Dec 16 01:01:01 vici1 /usr/sbin/cron[24588]: (root) CMD (/usr/share/astguiclient/AST_vm_update.pl)
Dec 16 01:01:01 vici1 /usr/sbin/cron[24589]: (root) CMD (/usr/share/astguiclient/AST_manager_kill_hung_congested.pl)
Dec 16 01:01:01 vici1 /usr/sbin/cron[24592]: (root) CMD (/usr/share/astguiclient/ADMIN_keepalive_ALL.pl)
Dec 16 01:01:01 vici1 /usr/sbin/cron[24593]: (root) CMD (/usr/share/astguiclient/AST_CRON_audio_2_compress.pl --GSM)



The agents log out from the astguiclient at 1. I am not sure what is causing this as I disabled the cron as you told.

Can it be an apache issue ? If I reload apache , can it cause all the agents to logout ? May be there is a code that is restarting apache, what do you say ?

[williamconley]

What I am saying is that "cron" scripts that are set to run at ONLY 1AM (or 1AM and 7AM) are set that way to AVOID running when agents are on the system. IF you have agents on the system at that time, MOVE THEM ALL away from that time slot.

The question is: when is your system NOT in use so you can run those "overnight" scripts?

I'm not suggesting that this will resolve the issue, rather that these scripts are meant to run during down time anyway, so moving them is not a bad thing, and if you move them to ANY other time, you may notice that the LOGOUT moves with one of them ... thus allowing you to drill down and find your problem.

[circuit]

OK, I got what you are saying.

There are 2 slots in which we have downtime.

1. 7 : 15 AM - 7 : 50 AM
2. 9 : 15 PM - 9 : 50 PM

So from you last post, definitely, you are suggesting to run these scripts in downtime. These have to be run, we cannot avoid that for performance.

Here is my question, I have a list of astguiclient crons, If I look at my log, these are the ones that run at 1 : 00 AM,

Code: Select all


Dec 16 01:00:01 vici1 /usr/sbin/cron[24236]: (root) CMD (/usr/share/astguiclient/AST_VDhopper.pl -q)
Dec 16 01:00:01 vici1 /usr/sbin/cron[24245]: (root) CMD (/usr/share/astguiclient/AST_manager_kill_hung_congested.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24249]: (root) CMD (/usr/share/astguiclient/ADMIN_keepalive_ALL.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24243]: (root) CMD (/usr/share/astguiclient/AST_vm_update.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24251]: (root) CMD (/usr/share/astguiclient/AST_CRON_audio_1_move_VDonly.pl)
Dec 16 01:00:02 vici1 /usr/sbin/cron[24240]: (root) CMD (/usr/share/astguiclient/AST_conf_update.pl)


Now out of these, this is the one that runs at 1 AM and 7 AM,

Code: Select all

### 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 --postal-code-gmt


The question is that I had my agents logged in. Then, I ran the above cron manually from the CLI. I saw the output on the CLI, However, none of my agents were logged out from astguiclient, so, how can this be the one that causes the agent log out? Although, Yes, it does run at 1 AM and 7 AM.

May be there is a whole sequence that causes the logout ?

2 more questions,

1. Does the sequence of execution matters? I believe it does, so I am just concerned, if I move the timing of one, the ones before and after should also be moved, right ?

2. I have a multi server environment with load balancing, If I disable the crons on one machine, is there a chance that the crons executing on the other servers may still affect this machine ? OR does the crons have an impact locally? When I say crons, I mean "astguiclient crons" in a load balancing environment.

I am not expecting a solution. However, I do expect that I get more insight to the behavior of how the whole system works.

[circuit]

Also William, what was I thinking what if I disable all the crons and then test?

But again, If I know what these crons do, it'll make more sense which ones to disable for testing ....

[williamconley]

the sequence matters only to a slight degree for the sound mixing/moving scripts.

ANY script that only runs one or two times a day can be moved to ANY time.

IF the "problem" is being caused by a "group" of crons executing at the same time ... moving the "dailies" away from 1AM into your 7:30AM downtime may resolve your issue entirely!

the script that runs at 1AM and 7AM can be moved to 7:30AM and 9:30AM without hurting your system.

Scripts that run every 3 or 4 minutes CAN skip ONE of those without harm (ie:
0,3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57 can be changed to 3,6,9,12,15,18,21,24,27,30,33,36,39,42,45,48,51,54,57)

[circuit]

Thank you,

I do know now that by rescheduling the crons, I may be able to overcome the issue. However, here is what I am going to ask you again as in my last post,

This is the one that runs at 1 AM and 7 AM,

Code: Select all

### 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 --postal-code-gmt


The question is that I had my agents logged in. Then, I ran the above cron manually from the CLI. I saw the output on the CLI, However, none of my agents were logged out from astguiclient, so, how can this be the one that causes the agent log out? Although, Yes, it does run at 1 AM and 7 AM.
[/code]

[williamconley]

what makes you think it is JUST that one item that causes the logout?

it may be something else

it may be a combination of things

it may be RULED OUT by moving to another time slot, and then you can go on to look at other things.

[circuit]

The fact that this cron runs at 1 AM and 7 AM is a strong indicator that this should be it. If not whole, then it may be playing a part.


Do we have any assistance in the developer's section that what these crons do ? I wasn't able to find any documentation on this.

[williamconley]

to be clear: your method of troubleshooting is ... since these run at 1 and 7, you'll pick them clean to find out why they are causing it ... instead of moving them to 7:30 and 9:30 (which does no damage) to see if that resolves the issue?

the files themselves (the perl scripts in this folder) all have notes as to what they do.

[circuit]

OK, I am going ahead and doing that now. I was a bit reluctant as this is a production machine.

Just one last question, there is no Vicidial setting in the Admin interface that can cause this, right ?

[williamconley]

are you using the agent timeclock system at all?

[circuit]

I am not sure. Supposedly yes, what does it do ? Can it cause a log out as well ? I have done some googling on it. As per my understanding it is meant to track agent login time only ?

Please correct me if I am wrong.

[circuit]

Do you know where to DISABLE timeclocks for a campaign or a user? I think this may be controlled from the admin interface itself.

[circuit]

While googling, I have also come across "Shift Enforcenment", It is OFF at my end. But again, it does log agents as well, right? I mean it does a force log out.

[enavaro]

Hi,

I have the same problem encountering with the fresh install of latest goautodial-ce-final.iso downloaded at the goautodial website.

First, I thought it was an error got from downloading the said installer. Then I download another one.

We experience auto log-off and the client interfaces shows "Session has been disabled".

We experience these from 1am and 7am Philippines Time.

I searched around and look for a solution for these and saw only this Topic of circuit.

It was very annoying when we are in the peak of a call and suddenly our calls cut-off.

Here was my procedure of installation:

1. Download the latest goautodial installer (Dec. 17, 2010)
2. Install it to the server - Quad Core, 4GB RAM, 1TB HDD
3. No Sangoma and Digium Hardware
4. Set the HWclock and System clock at GMT +8
5. Set the Vicidial and Phone at GMT +8
6. Put the VoIP provider in the Carrier Section
7. Test calls and customer time if they are good.
8. Create Campaign and other related things like (lead recycle, Statuses Dispo etc.)
9. Upload all the related leads for the Campaigns
10. Change the root password and Vicidial Admin password

Finally system is ready for production.

And now every 1am and 7am agents we are auto-logout and show the "Session has been disabled"

Is there anyone experiencing this problem beside circuit and me?

Please if there is anyone know the solution, help us.

enavaro

[williamconley]

have you considered trying vicibox redux to see if the problem persists there or is limited to the goautodial distro?

[enavaro]

Hi William,

I love to try the Vici Redux! In fact before I installed goautodial I tried to install Vici Redux 3.0.0.9 in the said hardware. And see what was the difference from goautodial. But the owner is very much a hurry to up the system in just a day. So no choice but to install goautodial because our workstation where configured the way with vicidialnow CE 1.3.

So I need the pre-configured phone set-up and others from goautodial. And also I'm more comfortable with the CentOS.

Learning SuSE would take time for me to study.

I am thinking, if (possible) that the crons (scripts) schedule 1:01am and 7:01am is the cause. It is related to the Timezone that I change?

Because by default the goautodial was at the GMT -5.

I am thinking to set these timezone back what was it before in default. But it always good to set your server timezone in correct country time.

What do you say?

enavaro

[williamconley]

i have registered my opinion rather loudly already

lots of posts from me in this one. Opinion hasn't changed: If you want to find it, move the daily crons away from 1AM to see if that resolves it.

if you want it to "go away", switch to vicibox (and take your database with you, because you can!).

If it works, at least you have a "base" and can now find the "difference".

In your situation, though, considering your comfort with CentOS: I would turn off or reschedule any crons away from 1AM and NOT use any timeclock functions between Midnight and 2AM. To Test.

[circuit]

I have shifted the cron timing.


Also, I did it first through crontab -e, but that had no effect.

Then I found a few more files that could be causing this,

Goto /usr/src/astguiclient

and edit the crons time changes in rootcron and vicicron also.

I am going to check and see tonight if my agents log out today.

Also, I do have a hunch that changing the GMT may help. This is the GMT for that particular user right ? It is not going to affect the other users on the box.

[circuit]

OK , This is for you enavaro

My phones have by default - GMT , yet they are logging out. So, I don't think that is going to affect the log out issue.

[williamconley]

/usr/src/astguiclient

files in this directory are not active. this is a staging area only.

[circuit]

OK guys,

The script that causes the logout is,

/usr/share/astguiclient/AST_reset_mysql_vars.pl

If you open up the file, it would explicitly state that do not run this script while your agents are logged in. This one actually runs at 1 : 02 AM.

This one runs only once in 24 HRS. So by rescheduling this to your server downtime resolves the issue permanently. The agents did not log out in my case.

I am still monitoring my machine meticulously, I am unsure of what impact it may create after the schedule. So far, it is looking good.